GNOME Bugzilla – Bug 495825
Slow startup when launched for viewing an image located in a crowded directory
Last modified: 2021-06-19 08:46:06 UTC
If you launch eog for viewing an image which is located in a directory full of images (5000), eog startup is too long (20 s). It probably scans for all files before showing anything. I think it would be nice if it could first display the requested image, then do the scan in an idle loop.
Emmanuel, which version of EOG are you using? This is most likely fixed in 2.20.x.
It's eog 2.20.1.
Created attachment 103741 [details] [review] disable sorting while adding a directory
Hmm, somehow the comment got lost for the attachment. So, could you give this one a try? It disables the sorting for the model while adding a directory to avoid constant resorting. I guess this is what was originally intended here anyway.
*** Bug 512318 has been marked as a duplicate of this bug. ***
*** Bug 514971 has been marked as a duplicate of this bug. ***
I ran eog in a cairo/tests directory with about 5000 images. According to sysprof, about 67% of the time is spent on sorting. After having applied your patch, the directory loads much faster and less CPU usage is consumed (your optimization was obviously needed, I wonder why I didn't add it from the beginning). After the patch, the left bottlenecks are: - Detection of the mimetypes: 30% - gtk_recent_manager_init: 20% So, Felix, please go on and commit your patch. Regarding the detection of the mimetypes, it makes sense to display the requested image and only check for every image's mimetype if the thumbpane is visible, otherwise, do it in a idle callback. I would love to work on this, but I don't think I'll have time before 2.22.
Committed. 2008-02-08 Felix Riemann <> * src/eog-list-store.c: (eog_list_store_add_uris): Disable sorting while adding a directory to the collection. This should improve the startup time in huge directories. Improves bug #495825.
I am the poster of bug reported on Gentoo (here as Bug 514971) I tested the patch proposed here on Gentoo 64bits; AMD X2 4200+; eog-2.20.4. My case might be extreme (15k images), but this patch does not bring the opening of eog to a reasonable speed. I interrupted the process after 1 minute. For comparison "gqview one_file.jpg" on same folder open in less than 2 seconds.
Christophe, your problem now are probably the "30% mime detection" Claudio mentioned. As we force mime sniffing during the model creation every file has to be opened and a sample needs to be taken. This is taking some time, especially with 15000 images. I'm not sure but GQView is I think only doing some filename matching to determine if a file is supported or not (which is of course faster). Hmm, could be worth a try checking if "normal" mime checking is sufficient for EOG during the model creation as well.
Even if my extreme case is not supported by eog (which I can somewhat understand), the lack of feedback during the "opening" gives the impression that either the program has crashed or worst froze the computer as it takes 100% CPU. There should be a way to regain control - short of using pkill. A kind of "cancel" button while opening.
I'll be working on improving EOG's startup time and responsiveness, but unfortunately, not now. I happen to be quite busy at the moment, so I'll probably look deeply into this during the next cycle.
*** Bug 521473 has been marked as a duplicate of this bug. ***
(In reply to comment #10) > > Hmm, could be worth a try checking if "normal" mime checking is sufficient for > EOG during the model creation as well. > FYI, we will probably have to do this anyway once the remaining parts of the GIO patch (bug 509239) are being merged. GIO doesn't have a way to force mime-sniffing. This means we need to do the sniffing ourselves (as we need the precise mimetype for the initial loader selection), which I would postpone until we are actually loading the image when we are reading the file anyway.
Hi! Could you give a status-update on this issue? Thanks.
Hi. eog . in a local directory with more than 16000 tiny images (250 MB) opens in 5 seconds. Which is fine for me. I still think it would be even greater if eog could display immediatly the requested image, then parse the directory for the other images (ideally in an asynchronous way http://log.ometer.com/2008-09.html#7 :) ). Thanks for your work ! Emmanuel.
(In reply to comment #15) > Hi! Could you give a status-update on this issue? Thanks. > Well, the situation should be a bit improved with 2.23/2.24 for now as these versions don't forcibly do mime sniffing due to GIO (see my comment 14) and we didn't get around to try implementing it ourselves. Asynchronically parsing the directory (as proposed by Emmanuel, IIRC this was proposed somewhere else already as well) showed some potential in a quick test but it will also need some time to fix threading and path lifetime issues with the ListStore.
*** Bug 500772 has been marked as a duplicate of this bug. ***
*** Bug 517032 has been marked as a duplicate of this bug. ***
Does eog "display" the next image into memory before actually displaying the image by performing a simple copy of the buffer to the video memory ?
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/eog/-/issues/ Thank you for your understanding and your help.