BestImageViewer / geeqie

claiming to be the best image viewer / photo collection browser
http://www.geeqie.org/
GNU General Public License v2.0
472 stars 78 forks source link

Geeqie slowed by scanning directory when starting or saving keywords. #1239

Open Aouxr opened 8 months ago

Aouxr commented 8 months ago

Setup (please complete the following information):

Describe the bug Geeqie scans the entire directory when starting, and when saving keywords. This makes it slow to start in directories with many photos, and slow to save keywords if that directory happens to be on a LAN network share.

To reproduce Start Geeqie in a folder with many photos. Geeqie takes a while to appear. In my folder of 2500 photos on my desktop, Geeqie take 10 seconds to appear. In my folder of 1500 photos on a LAN network share, Geeqie takes 15 seconds to appear.

Saving changes to the keywords of a photo also causes a delay, but only on the LAN network folder. In my folder of 2500 photos on my desktop, Geeqie does not lock up for a long enough period of time for me to notice it. In my folder of 1500 photos on a LAN network share, Geeqie locks up for 15 seconds.

During each example above, setting debug level to 1 shows many lines of output that look like the following during most of the delay period.

TG: basename_hash not found for /home/user/Desktop/EnormousFolderOfPhotos/0517.jpg

Expected behavior I do not see the need for scanning the entire directory when saving image metadata, especially when the setting "write metadata on image change" is selected. As for the slow initial startup, it would be very nice if Geeqie would start with just the selected image, and then load the rest of the folder after coming up, and without locking up.

PS. Thanks for all your hard work. The new release is awesome!

caclark commented 8 months ago

Geeqie version: Continuous build pre-release AppImage (2.2+git20240128-87ff30b3 GTK3)

Referring only to the AppImage aspect - on my laptop, $HOME/bin/Geeqie-latest-x86_64.AppImage / takes about 7 seconds to load. Please see the README for a way to negate this.

Aouxr commented 8 months ago

Thank you for your quick response. I did read the README before installing, and used the script to download and install the (full version) appimage with the -e option to extract the appimage, which should make the appimage loading and run time the same as for a packaged release, according to the README. The delay times that I am reporting were tested with this extracted (full version) appimage install. I suppose this is what you are telling me about in the README?

I just decided to do some testing with an older non-appimage version, so I installed the packaged release (geeqie v 2.1) from the archlinux "extra" repository with my package manager. Here is the data from this test (with the default config file).

Start Geeqie v 2.1 in a folder with many photos. Geeqie takes a while to appear. In my folder of 2500 photos on my desktop, Geeqie take 3 seconds to appear. In my folder of 1500 photos on a LAN network share, Geeqie takes 45 seconds to appear.

Saving changes to the keywords of a photo also causes a delay, but only on the LAN network folder. In my folder of 2500 photos on my desktop, Geeqie does not lock up. In my folder of 1500 photos on a LAN network share, Geeqie locks up for 12 seconds.

It appears that something in the new appimage version has greatly improved startup time on my LAN network share, but slowed down startup on my hard drive significantly. Also, these tests with geeqie version 2.1 do not show any debug output in the terminal, even with debug level set to --debug=4, but I suspect geeqie 2.1 is still scanning the directory during the initial start-up delay and the freeze-when-saving-metadata delay, based on output from strace.

I hope this info is helpful.