After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 679076 - Heavy I/O makes Gimp incredibly slow
Heavy I/O makes Gimp incredibly slow
Status: RESOLVED FIXED
Product: GEGL
Classification: Other
Component: GeglBuffer
git master
Other Linux
: Normal major
: ---
Assigned To: Default Gegl Component Owner
Default Gegl Component Owner
Depends on:
Blocks:
 
 
Reported: 2012-06-28 16:44 UTC by Helmut Jarausch
Modified: 2013-11-21 00:34 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Helmut Jarausch 2012-06-28 16:44:25 UTC 
Display a freshly opened file goes like slow motion.
Trying to draw a bit makes my system totally unresponsively.

It's doing tons of I/O mostly to
open("/home/jarausch/.cache/gegl-0.2/swap/2862-39", O_RDWR|O_CREAT, 0770) 
= 13

and or several sockets.

This is (babl/gegl/gimp) GIT from 2012/06/28

Helmut.
Comment 1 Helmut Jarausch 2012-06-29 08:09:25 UTC 
(In reply to comment #0)
> Display a freshly opened file goes like slow motion.
> Trying to draw a bit makes my system totally unresponsively.
> 
> It's doing tons of I/O mostly to
> open("/home/jarausch/.cache/gegl-0.2/swap/2862-39", O_RDWR|O_CREAT, 0770) 
> = 13
> 
> and or several sockets.
> 
> This is (babl/gegl/gimp) GIT from 2012/06/28
> 
> Helmut.

Let me add that this is on a quad core 3 GHz machine with 8 Gb RAM, 4 Gb beeing free while Gimp is running.
Helmut.
Comment 2 gerard82 2012-07-04 10:00:30 UTC 
I have the same problem with similar hardware.
The git compile is from july 3 2012.
Gerard.
Comment 3 Michael Natterer 2012-07-04 20:07:15 UTC 
The port to GEGL is not finished, and this problem will go away once it
is. Please use 2.8 if you want stable code.
Comment 4 gerard82 2012-07-05 14:19:24 UTC 
OK.
No hurry.
Thanks for all the work you do.
Gerard.
Comment 5 Daniel Sabo 2013-10-09 17:36:06 UTC 
We've been threw a few rewrites of the relevant code, is this still happening to some people?
Comment 6 Daniel Sabo 2013-11-21 00:34:24 UTC 
I can't replicate this anymore. I believe it was fixed when we switched to a single swap file, which removed all the flushing the old version would do as buffers were destroyed.