GNOME Bugzilla – Bug 742909
GIMP uses more system resources than necessary
Last modified: 2015-07-21 18:13:39 UTC
I am using GNU Image Manipulation Program version 2.8.14 on Ubuntu 14.10 x64 on my AMD Phonom II X4 machine packed with 8GB DDR3 RAM and more than the recommended amount of SWAP-Space found in multiple locations throughout my PC, and even though I have all this caching space and more plus a powerful processor, GIMP still eats my computer's system resources alive even while doing some quick editing and touch-ups, specifically when using the Heal tool - The window will freeze up and continue what it's doing in the background, but for that time being, it won't let me do much besides that. It has now gotten to a point where GIMP uses so many system resources all at one time where it locks up my (USB 2.0) keyboard for all apps and won't let me use the keyboard at all until GIMP is done doing what it is doing. I have even switched to the LowLatency Linux Kernel to help speed up my PC and keep only needed background tasks while using minimal RAM. See below for a HardInfo chart I pasted stating my Operating System information: -Version- Kernel : Linux 3.16.0-29-lowlatency (x86_64) Compiled : #39-Ubuntu SMP PREEMPT Mon Dec 15 22:55:59 UTC 2014 C Library : Unknown Default C Compiler : GNU C Compiler version 4.9.1 (Ubuntu 4.9.1-16ubuntu6) Distribution : Ubuntu 14.10 -Current Session- Computer Name : SDB User Name : jeb (Jeb Eldridge) Home Directory : /home/jeb Desktop Environment : Unity (ubuntu) -Misc- Uptime : 1 day, 16 hours and 52 minutes Load Average : 0.29, 0.44, 0.76 Attached is also a screenshot with "About This Computer" info shown.
Created attachment 294514 [details] HARDINFO REPORT Attached here is a full HardInfo Report on my PC, containing all hardware and kernel specs.
The more interesting information would be features of the image you are working on - it's size in pixels for one, the number of layers, and such. Also, the settings of the tools you were using, especially the brush sizes and type of brush (in order to judge its complexity). You specified that the resources consumed are "more [...] than necessary". If you have done some calculations of how much should be needed, this would be interesting as well.
The image size isn't extraordinary. It's a simple Jpeg file from a modern cell phone camera, the LG G3 to be precise. Image type: jpeg Width: 4160 px Height: 2340 px Exposure time: 1/1538 sec ISO: 50 Focal length: 4.0 mm I'll attach the file I'm currently working on in the next post :)
System monitor status during a simple touch-up using "Heal" in GIMP. This is the exact same file I was editing from yesterday with the same apps open at the same time, ceteris paribus. I could not perform a screenshot while GIMP was incoherent in the background, forcing me to grab my phone to snap this picture. As you can see, CPU usage goes through the roof in all four cores and fluctuates quickly between using 100% of per-core power to much less, almost like each core is taking a break or trying to push power elsewhere. RAM usage actually appeared to be pretty stable though, so maybe this was not a RAM issue too much at all? The picture was too large to attach... Here is the link to it on Flickr: https://www.flickr.com/photos/64718148@N06/16099603370/
I can confirm that it is rally slow to use a big heal brush. (Tested with Windows 7 and the CPU is an Intel Core i7-2720QM 2,2 GHz ) What we see on this screenshot is: 1. Only one CPU is used (but the used CPU changes) 2. You are using a relative big brush (275) 3. The RAM usage doesn't go higher, so this is not a RAM problem. Possible optimizations could be: - Parallelize the tool to use all CPUs. - Optimize the algorithm to work faster. - Use a faster CPU. - Use a smaller brush.
Understandable with the CPU aspects, but the reason I chose a large brush was purely for demonstration purposes. Both large and small brushes lag considerably, the larger lags earlier in the image restoration process though and takes a little longer, thus I could snap a screenshot quicker. And you are also right about the RAM issues, I did mention at the end of my previous comment that it probably has nothing to do with RAM. At the end of it all, it's still not the end unfortunately, because the program still takes up considerable system resources. The algorithms need to be refined or replaced with something new that supports multiple threads via multiple cores at one time.
Please check if this is a duplicate of bug 736411. (try disabling the rulers and report back)
Jeb, can you have a look at comment 7?
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment. Thanks!