GNOME Bugzilla – Bug 145283
gimp gets slow with age (as do we all)
Last modified: 2004-12-27 23:48:51 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.
Use a stable version then or at least use the latest development version. Submitting bug reports for outdated development versions is rather rude behaviour.
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.
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.
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 you? 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".
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.
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.
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?
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.
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.
Jamie, have you had the chance to update to 2.1.4 and try to reproduce your problem?
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.