I have recently installed 2.9.8 after working extensively with 2.9.5 and it is so much slower. I also tried 2.9.6 in the past and now again and it also was much slower than 2.9.5.
I now understand why everyone was going “C2G is just sooo slow that I can’t use it” in my enhancing local contrast post. It is basically unusable now, while it was just slow in 2.9.5
Why is that?
And can I do something to make 2.9.8 faster?
Thanks
Stephan
I checked the Color to Gray and yes, it can be very slow for high values of ‘iterations’. If the ‘iterations’ is kept slow around 1 or 2 than it is fast for a 12M photo.
What size is your photo?
How many ‘iterations’ do you need?
Ultimately, if the performance is lower than in previous versions of GIMP, you should file a bug to https://bugzilla.gnome.org/enter_bug.cgi?product=GIMP
as far as c2g goes I filed a bug noting threads was a problem and they mentioned
“multiple nearest neighbour samplers” is one of its problems
I’ve been wondering whether to move on from 2.9.5, perhaps I’ll leave that for a while in view of what you say.
One thing though, I’ve left the no. of threads at 1 in Preferences, due to the warning message there. Have you tried multi threads, and if so how did it go, please?
It looks like c2g “is already quite slow in single-threaded, but as multi-thread, it is just slow as hell” (see bug Bug 791424 – multithreading slows down color to grey).
However, things might have been mitigated and performance might the same using singltthread or multithread processing, according to the last commit by Kolas.
In case it came across as such, I am not only talking about C2G but about gimp speed in general. All my basic steps (desaturate, overlay layers, etc…) are slower.
I tried single vs. multithreading without noticable difference. Interestingly also working on a tif (~90MB) and working on a jpg (~10MB) felt quite similar.
Maybe I’ll have to read up on how to file a bug.
Where does your build come from? The performance problem could come from some debug option left in by the people who built your specific version…
I would recommend building GIMP GIT locally using Elle Stones’ script:
https://ninedegreesbelow.com/photography/build-gimp-in-prefix-for-artists.html
Let me know if you’re using Arch, as I have a version of the script specific for Arch.
That’s to be expected if the files have the same pixel dimensions. The compressed JPEG has the same amount of pixels to shuffle around.
If you are talking about a JPEG with significantly smaller pixel dimensions than the TIFF its more surprising.
Just an update.
I deinstalled all previous versions and installed @partha’s 2.9.6 portable version. Now the speeds are back to what I was used with 2.9.5.
Color to Gray takes around 6 seconds on a 4700x3200px image. Other operations like desaturate only take a short breath and even large gaussian blurs, 200px, don’t take longer than 1-2 seconds.
With the non portable version 2.9.6 even desaturating took several seconds. Color to Gray was basically unusable
I don’t know why that is, but maybe this information helps somebody.
PS: I’m running on one thread.
The portable version isolates the system from the app. It does not use
your personal GIMP folder. Perhaps something there is slowing things down?
Also, what is your environment variable GEGL_CACHE_SIZE set to?
Hi, I would like to test out the arch specific script please.
This observation is about painting with a brush, so perhaps not relevant. But painting at 32-bit floating point linear precision is a lot faster than painting at 32-bit floating point perceptual precision. So it might be worth comparing the speed of the C2G operation at “linear” vs “perceptual” precision.
This is for 2.9.8 updated through yesterday. Normally my images are at 32f linear, so I hadn’t ever noticed the discrepancy in painting speed, until today when I was checking something related to ICC profile conversions.