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 660278 - GIMP is slow to quit/exit
GIMP is slow to quit/exit
Status: RESOLVED NOTABUG
Product: GIMP
Classification: Other
Component: User Interface
2.8.4
Other Linux
: Normal normal
: ---
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks: 141797
 
 
Reported: 2011-09-27 18:34 UTC by Jean-François Fortin Tam
Modified: 2013-10-04 20:24 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jean-François Fortin Tam 2011-09-27 18:34:57 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.
Comment 1 Michael Natterer 2011-09-27 18:38:58 UTC
Does this still happen in 2.7.3? We won't do anything about 2.6 slowness.
Comment 2 Jean-François Fortin Tam 2011-10-23 19:07:02 UTC
I just tested now and it indeed happens (same benchmark results) on 2.7.3.
Comment 3 Michael Natterer 2012-01-08 20:28:24 UTC
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.
Comment 4 Jean-François Fortin Tam 2012-01-09 18:08:12 UTC
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.
Comment 5 Michael Natterer 2012-01-09 19:03:22 UTC
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.
Comment 6 Jean-François Fortin Tam 2013-06-15 15:17:59 UTC
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.
Comment 7 Michael Natterer 2013-06-15 16:13:12 UTC
What do you think is the bug here? We do IO on quit, and that takes some
time.
Comment 8 Jean-François Fortin Tam 2013-06-17 18:12:35 UTC
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 :)
Comment 9 Michael Schumacher 2013-06-17 18:25:33 UTC
Did you verify that e.g. brush and gradient files get written even if they have not changed?
Comment 10 Jean-François Fortin Tam 2013-06-17 18:58:10 UTC
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.
Comment 11 Michael Schumacher 2013-10-04 11:17:45 UTC
I think we can finally resolve that as NOTABUG then.
Comment 12 Jean-François Fortin Tam 2013-10-04 17:36:17 UTC
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.)
Comment 13 Michael Natterer 2013-10-04 17:42:51 UTC
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.
Comment 14 Jean-François Fortin Tam 2013-10-04 20:18:31 UTC
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 ;)
Comment 15 Michael Natterer 2013-10-04 20:24:44 UTC
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" :)