GNOME Bugzilla – Bug 660278
GIMP is slow to quit/exit
Last modified: 2013-10-04 20:24:44 UTC
When quitting GIMP (with ctrl+Q), it takes a long time for it to actually exit: - 4 seconds on a dual core "pentium" with conventional HDD - 3 seconds on a core2quad + SSD drive Those results are warm times, with no image open at all.
Does this still happen in 2.7.3? We won't do anything about 2.6 slowness.
I just tested now and it indeed happens (same benchmark results) on 2.7.3.
Stable versions quit using exit(), unstable ones shut down everything properly for debugging purposes, closing as NOTABUG because it doesn't happen in stable. If it still happens in 2.8 once it's out, please feel free to reopen.
No. My initial bug report here was on 2.6, then you told me you wouldn't do anything about that stable release. Then I tested on 2.7.3 as you requested and reported that the same problem occurs on that development version too. This is not caused by a dev environment. I might add that while quitting, there's a bunch of I/O going on.
In stable, GIMP is saving its settings, and all dirty data like generated brushes and gradients, and then calls exit() without closing any windows or anything. I just tried and enabled the exit() that is used in stable, and quit time was always under one second, with and without images open. Closing as NOTABUG again, feel free to reopen if quitting remains slow for you once 2.8 is out.
Yep, unfortunately still a bug in 2.8.4. Same three seconds to quit the app. Same 3.5 seconds to exit the app, with some IO going on.
What do you think is the bug here? We do IO on quit, and that takes some time.
Hi Michael, there are few things that come to my mind. Most optimization/perf problems are simply about doing too much work at the wrong time, or doing work that does not need to be done at all. Let me then prompt you with some questions as food for thought: - Why do you (re)write brush files and gradients and all those things if they haven't actually changed? I can't recall editing GIMP brushes or gradients in the last five years. Doing IO would be fine if the brushes actually changed in the current instance, otherwise the app is doing excess work. - Even in the case where it writes everything everytime, does the IO truly have to happen on exit instead of happening when changes are done? For example, saving the user settings after he clicked the "OK" button and the settings window has been closed - I expect settings saving to be a lightweight operation which wouldn't take more than 0.1 second (or there's a big performance bug to be fixed right there :). Similarly, brush changes could be written to disk... well, once the user confirmed changes made to a brush. A side-effect of fixing that is that you prevent user settings/data loss that may occur if GIMP crashes (although I've almost never seen that happen :) *Worst case scenario*, if you really can't do otherwise (that would be surprising, I trust that you can come up with a brilliant solution for this :) - then a workaround would be to hide the window while the remaining IO happens in the background. In other words, "faking" it. But I hate the thought of hiding problems under the rug :)
Did you verify that e.g. brush and gradient files get written even if they have not changed?
No, I was just guessing from what you said previously (you seemed to say that brushes and other things are written to disk on exit, so I thought it was done in such a way that explains the consistently slow quit times on my desktop machine. Interestingly enough, it seems my other machine's hard drive is "too fast" to properly reproduce this, so if you think this can be useful I could run sysprof while exiting GIMP on the machine where the slowness is more noticeable.
I think we can finally resolve that as NOTABUG then.
Michael, how did you arrive at that conclusion? In comment #5 Michael Natterer mentioned brushes and such being slow to write, "reopen if it still happens with 2.8"... then in comment #7 he basically asked "so what's the problem with taking time to happen on quit" to which I replied in comment #8. And then in my last comment I asked which information I should provide to make it easier for you to pinpoint the actual problem, I was waiting for that... Are you now closing this because there's a fix in git I'm unaware of, or because you require your users to have top of the line solid-state drives and just don't want to fix it (which is okay I guess, that's your maintainer discretion, but I need to know)? (I'm not here to file bugs to make your life harder, I'm offering my help to provide information to corner down this issue and make the software better, to the extent of the tools available to me.)
You said it takes between 3 and 4 seconds, and it's somewhat unclear how that is "slow". Yes there are some things that happen at quit and of course some of them can be made faster. But with the same logic a "foo is slow" can be filed against *every* part of GIMP, because every part does something and every part can probably be optimized.
I see your point. Maybe I have unreasonable expectations for GIMP to exit "instantly" (by that I mean within ~500ms) when requested to do so. The thing is that every other "comparatively complex" application I've seen out there (Inkscape, LibreOffice, Blender, browsers with dozens of tabs, music and video players, video editors, etc.) quits immediately when requested. You ctrl+Q or click the Close button and poof, it's gone. I'm still happy to provide quantitative/profiling/debug data (I just need to know what you need from me!). If you're not interested in nailing down this issue however, that's your call - I'll just move on with life ;)
Some of these simply hide their windows first, then do all the other stuff, might be something to consider for GIMP. However, in pathological situations it might really take *long* to do something on quit, and e.g. logging out or shutting down before might lead to a data loss. Besides, I still don't think that 3-4 seconds is "long" :)