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 500772 - eog is slow at loading JPG
eog is slow at loading JPG
Status: RESOLVED DUPLICATE of bug 495825
Product: eog
Classification: Core
Component: image viewer
2.20.x
Other Linux
: Normal normal
: ---
Assigned To: EOG Maintainers
EOG Maintainers
: 510729 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2007-12-01 00:44 UTC by alexandreracine
Modified: 2012-03-13 22:28 UTC
See Also:
GNOME target: ---
GNOME version: 2.19/2.20


Attachments
picture1 (91.39 KB, image/jpeg)
2007-12-04 00:38 UTC, alexandreracine
Details
picture2 (84.70 KB, image/jpeg)
2007-12-04 00:38 UTC, alexandreracine
Details
comparing eog and gliv's cpu usage (50.78 KB, image/png)
2008-01-20 20:40 UTC, Jean-François Fortin Tam
Details
Loading 15 photos with oeg one after the other (59.04 KB, application/octet-stream)
2008-01-26 14:51 UTC, alexandreracine
Details

Description alexandreracine 2007-12-01 00:44:54 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
Comment 1 Lucas Rocha 2007-12-03 23:07:25 UTC
Alexandre, thanks for your report. Feel free to attach the two example images here. 
Comment 2 alexandreracine 2007-12-04 00:38:07 UTC
Created attachment 100158 [details]
picture1

picture1
Comment 3 alexandreracine 2007-12-04 00:38:58 UTC
Created attachment 100159 [details]
picture2

picture2
Comment 4 alexandreracine 2007-12-04 00:40:05 UTC
Ho yeah, I can add some attachement :)

Comment 5 alexandreracine 2007-12-25 17:17:55 UTC
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.
Comment 6 Claudio Saavedra 2008-01-14 13:08:51 UTC
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.
Comment 7 Claudio Saavedra 2008-01-20 05:47:17 UTC
*** Bug 510729 has been marked as a duplicate of this bug. ***
Comment 8 Claudio Saavedra 2008-01-20 05:48:44 UTC
[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.
Comment 9 Jean-François Fortin Tam 2008-01-20 20:40:16 UTC
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.
Comment 10 Jean-François Fortin Tam 2008-01-20 20:40:49 UTC
Created attachment 103277 [details]
comparing eog and gliv's cpu usage
Comment 11 alexandreracine 2008-01-26 14:51:10 UTC
Created attachment 103777 [details]
Loading 15 photos with oeg one after the other
Comment 12 alexandreracine 2008-01-26 14:53:56 UTC
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.
Comment 13 Jean-François Fortin Tam 2008-03-13 14:13:11 UTC
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
Comment 14 Jean-François Fortin Tam 2008-03-18 21:27:48 UTC
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?
Comment 15 Stephan Michels 2008-03-31 15:50:26 UTC
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.
Comment 16 Pavel Šefránek 2011-07-03 16:18:43 UTC
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 ***
Comment 17 Adam Niedling 2012-03-13 22:28:49 UTC
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.