GNOME Bugzilla – Bug 500772
eog is slow at loading JPG
Last modified: 2012-03-13 22:28:49 UTC
Hi guys, here is what I sent to the guys at lauchpad (Ubuntu), they told me to go here, so here it is. "Mabey I am hard, but I am using irfanview on my Ubuntu machine with wine and the software is blazing fast compare to eog. For a small test, I loaded the first picture of 133 and started to look at the pictures as fast has I can for 15 seconds. With Irfanview, I go from 1 to 70 in 15 seconds. With eog, I go from 1 to 13 in 15 seconds. More notes -eog used my CPU even after stopping the test. -After loading the first image, Irfanview use 21MB, eog use 26,2MB -After looking at 100 pictures, irfanview use 23,1MB, eog use 30,6MB -eog use way more CPU power to do anything. Been really slow is a bug. Not a critical one, but still one." References : Wine : http://www.winehq.org/ Irfanview : http://www.irfanview.com/ Lauchpad : https://bugs.edge.launchpad.net/ubuntu/+source/eog/+bug/172719 The same things happen with only two pictures... I don't know if I can attach pictures with bugzilla, please look at the Lauchpad reference and download the two pictures from there. Thanks. Just for some stats... $ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel model name : Intel(R) Pentium(R) 4 CPU 2.60GHz $ uname -a Linux machine 2.6.22-14-386 #1 Sun Oct 14 22:36:54 GMT 2007 i686 GNU/Linux
Alexandre, thanks for your report. Feel free to attach the two example images here.
Created attachment 100158 [details] picture1 picture1
Created attachment 100159 [details] picture2 picture2
Ho yeah, I can add some attachement :)
Hi guys, Is it possible that the fact that there is 49000+ files in the .thumbnails/normal folder that would slow down things a little? I did a test by renaming the folder and it seems a little more faster.
One of the reasons for the slowdown in image switching was bug #505811, which is already fixed in trunk. I don't think there should be any slowdown due to the amount of pictures in .thumbnail.
*** Bug 510729 has been marked as a duplicate of this bug. ***
[Answer to Jeff, from bug #510729] Hm, one reason could be bug #505811, which is fixed in trunk. It would be interesting to get numbers for several use cases, so we can find out where the bottlenecks are. If you could give a test to trunk and see how it performs for you, run it under a profiling tool like sysprof, and attach the results here, we could do some analysis and find out the reasons.
well I have not seen a performance improvement running eog trunk (comparing with another similar machine with eog 2.20). However, I am unable to get consistent results. Images usually load between 3-6 seconds cold, and 2 seconds warm (but then... how come? eog is entirely freed from memory after exit no? why reopening the same image is faster?). I don't know what to think anymore, I can't really get the logic behind the slowness. The only thing I notice, however, is that eog uses my CPU a lot, I'll attach a small screenshot comparing the cpu spikes from my monitor applet.
Created attachment 103277 [details] comparing eog and gliv's cpu usage
Created attachment 103777 [details] Loading 15 photos with oeg one after the other
Thanks to the instructions here https://bugs.edge.launchpad.net/ubuntu/+source/sysprof/+bug/30160/comments/6 how to build the kernel module with Ubuntu, I was able to use sysprof with oeg 2.20.1. See the attachement in comment #11. What I am doing is simply loading 15 photos one after another. Theses are 5M+ photos. I did that on my new machine, but I could do it also on my old Pentium4 if needed. I hope this can help.
Ok, I just happened to use KDE today for some other bug report I needed to experiment upon. And I opened an image, a big jpeg wallpaper, and it opened in "kview", in LESS than a second, no cpu usage, nothing. And then I tried opening a 629x413 image on my gnome 2.20 desktop and it took 8 seconds. x__x
Did some more experimenting. Two things which seem to affect this issue, one of which (the second) is fixable I would assume: 1) GTK Recent is a piece of sh... I discovered today that ~/.recently-used.xbel was 5 *mibibytes* in size! That's about 60 000 lines of XML! Clearing this files speeds up gedit significantly (0 seconds instead of 5 seconds) for saving, and I think this also affects EOG. 2) Loading an image in an unvisited folder takes a slightly longer time than loading other images in the same folder afterwards, if I am perceiving correctly. My hypothesis here is that maybe EOG tries to read the list of files in the folder? If that is the case, could EOG be modified so that it *first* loads the image *completely*, and then it can have fun loading the directory list? Basically, do not interfere with the loading of the initial image?
I had the same problem. Switching images was not very fast. My .recently-used.xbel file had a size about 3MB. And I can confirm that deleting this files improved the speed of EOG drastically.
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of bug 495825 ***
Actually this is the duplicate of bug 321603. Bug 495825 is about eog being slow to start, bug 321603 is about eog does not preload the next/prev picture so it's slow for viewing pics.