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 145283 - gimp gets slow with age (as do we all)
gimp gets slow with age (as do we all)
Product: GIMP
Classification: Other
Component: General
Other Linux
: Normal normal
: ---
Assigned To: GIMP Bugs
Depends on:
Reported: 2004-07-02 02:56 UTC by Jamie Zawinski
Modified: 2004-12-27 23:48 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Jamie Zawinski 2004-07-02 02:56:54 UTC
I'm editing hundreds of pictures, one at a time.
I load them in from the shell with gimp-remote;
edit, save, close window; move on to the next.

By the time I have done this about 50 times, Gimp has
become noticibly slower.  *Closing* a window (which 
has already been saved) takes more than five seconds.
Just after Gimp has launched, that is basically instant.

I don't know any more about the cause than this, but
quitting and restarting Gimp speeds things up again,
until next time.

These are all very big files: 3072x2048 jpegs.

My preferences are mostly default, except for:

  Undo levels: 64
  Undo memory: 16
  Tile cache: 256

This is Gimp 2.1.0 on Red Hat 9.
Comment 1 Sven Neumann 2004-07-02 15:08:07 UTC
Use a stable version then or at least use the latest development version.
Submitting bug reports for outdated development versions is rather rude behaviour.
Comment 2 Jamie Zawinski 2004-07-02 18:02:31 UTC
Outdated?  I downloaded it *two weeks ago*!  It was the latest released
development version as of June 13.

WTF is your problem?  Excuse the hell out of me for trying to help you
make your program better.
Comment 3 Michael Schumacher 2004-07-02 18:39:05 UTC
Well, development releases are outdated when the next commit to CVS happens...

Your might have meant well, but using a less than recent release from the
development branch (instead of a at least somewhat recent build of HEAD) won't
help anyone, neither you who seem to use GIMP for production work nor the
developers, who are busy working on it.
Comment 4 Jamie Zawinski 2004-07-02 18:59:51 UTC
You're right, I'm sure the source of whatever problem I'm describing here has
changed incomprehensibly in the *two weeks* since I got my snapshot.  Surely the
internal memory management has changed so fundamentally in that time that my
data point can't possibly be relevant any more.  You haven't even tried it, have

I don't intend to spend more time *compiling* Gimp than *running* it, so I guess
I just won't bother you with bug reports any more.

I am using 2.1 because the EXIF support in all earlier releases ranges from
"broken" to "nonexistent".
Comment 5 weskaggs 2004-07-02 19:56:21 UTC
The last comment isn't really true, as far as we know.  EXIF support has hardly
changed in Gimp 2.1, so if you're using the same version of libexif and built
both versions with EXIF enabled, Gimp 2.0 should do just as good a job of
maintaining the EXIF data as Gimp 2.1.  If your experience has been different,
we would like to hear about it.

Anyway, the reason you are getting the non-cooperative responses is that the
most likely cause of what you are seeing is memory leaks, and there have been
numerous cleanups since 2.1.0 was released, so the results you are reporting are
in fact no longer relevant.  As a developer yourself, I'm surprised that you
didn't realize this.  In any case, Gimp 2.2 will not be released until it is
clean of any detectable leaks, so it is likely that your issue will
automatically be addressed in the natural course of things.
Comment 6 Sven Neumann 2004-07-02 20:06:38 UTC
I am sorry but EXIF support is functional in GIMP 2.0 and nothing has changed
with respect to EXIF in the 2.1 series.

We will definitely care about memory leaks when 2.2 is close. It doesn't make a
lot of sense to do that every so often during a development cycle. On the other
hand, I actually did it lately and there weren't any obvious memory leaks.

Unless you can provide a reproducable test case or memory profiling data your
bug report is rather useless at this point in development. We can however keep
it open  for now.
Comment 7 Simon Budig 2004-07-02 20:08:39 UTC
Actually it would be good to know, what "editing" an image does mean exactly.
Does it involve global changes, like using curves or levels? Does it involve
selections? Or is this just a local editing with the clone tool?

When the gimp stalls while closing the image, is there any indication of
activity like harddisk activity or increasing load? When closing the gimp, are
there any messages on the console?
Comment 8 Jamie Zawinski 2004-07-03 07:44:35 UTC
The editing I've been doing has been almost exclusively with the levels and crop
tools.  When it is stalled, I don't hear the disk making noise (but I might
not); I have not noticed the machine feeling slow, but I also wasn't watching
"top" at the time.
Comment 9 Sven Neumann 2004-07-03 09:42:36 UTC
I've done some testing with the current CVS version using crop and levels and
memprof doesn't report any significant memory leaks (there seems to be a minor
one in the splash screen code though). I am changing this report to NEEDINFO and
would like to ask Jamie to use at least 2.1.1 and report back.
Comment 10 Sven Neumann 2004-09-13 10:26:04 UTC
Jamie, have you had the chance to update to 2.1.4 and try to reproduce your problem?
Comment 11 weskaggs 2004-12-27 23:48:25 UTC
Of course GIMP is still too slow, but for quite different reasons by now. 
Closing as INCOMPLETE on the legalistic grounds that the reporter has not
responded to NEEDINFO, but really just because it would be better to open a new
report if there are specific speed issues than to add to this one.