Redundant file accesses leads to extreme slowness on high-latency remote mounts
Hi, I am now mounting my library directory over a high-latency link, almost 100ms ping. Both database and cache directory are local, on SSD, only the library is remote. Unfortunately Shotwell is almost unusable. I tried to debug it a bit, and here is the simplest case I found, with clear evidence of what can be improved:
I open Shotwell and the progress bar saying "checking for changes in library" (or similar text, I don't recall) keeps going forever. I leave it for 10 minutes, and then I ignore it - it shows it's still working, but the bandwidth monitor shows minimal traffic.
The simplest use case then is scrolling through my catalog of photos while viewing the thumbnails, single-clicking on one photo, and copying the full path of the photo in order to access the specific photo via other means. Single-clicking on a thumbnail freezes the UI and takes almost 30 seconds to unfreeze and display the information on the right panel. Bandwidth monitor shows minimal usage, so I assume there is a lot of back-and-forth conversation with metadata packets.
Here is a log from strace
showing some of system calls that shotwell does, while the UI is frozen:
17:34:59 openat(AT_FDCWD, "/home/jimis/Pictures/shotwell_import/2018/04/27/20180427_183406.jpg", O_RDONLY) = 23 <3.117285>
17:35:02 stat("/home/jimis/Pictures/shotwell_import/2018/04/27/20180427_183406.jpg", {st_mode=S_IFREG|0600, st_size=3392069, ...}) = 0 <2.195079>
17:35:04 openat(AT_FDCWD, "/home/jimis/Pictures/shotwell_import/2018/04/27/20180427_183406.jpg", O_RDONLY) = 23 <3.246312>
17:35:08 stat("/home/jimis/Pictures/shotwell_import/2018/04/27/20180427_183406.jpg", {st_mode=S_IFREG|0600, st_size=3392069, ...}) = 0 <1.683012>
17:35:09 openat(AT_FDCWD, "/home/jimis/Pictures/shotwell_import/2018/04/27/20180427_183406.jpg", O_RDONLY) = 18 <3.617272>
17:35:13 stat("/home/jimis/Pictures/shotwell_import/2018/04/27/20180427_183406.jpg", {st_mode=S_IFREG|0600, st_size=3392069, ...}) = 0 <1.417442>
17:35:15 openat(AT_FDCWD, "/home/jimis/Pictures/shotwell_import/2018/04/27/20180427_183406.jpg", O_RDONLY) = 18 <1.850784>
17:35:16 stat("/home/jimis/Pictures/shotwell_import/2018/04/27/20180427_183406.jpg", {st_mode=S_IFREG|0600, st_size=3392069, ...}) = 0 <2.272159>
17:35:19 stat("/home/jimis/Pictures/shotwell_import/2018/04/27/20180427_183406.jpg", {st_mode=S_IFREG|0600, st_size=3392069, ...}) = 0 <2.156070>
17:35:21 openat(AT_FDCWD, "/home/jimis/Pictures/shotwell_import/2018/04/27/20180427_183406.jpg", O_RDONLY) = 18 <1.881773>
17:35:23 openat(AT_FDCWD, "/home/jimis/Pictures/shotwell_import/2018/04/27/20180427_183406.jpg", O_RDONLY) = 18 <1.889379>
17:35:25 stat("/home/jimis/Pictures/shotwell_import/2018/04/27/20180427_183406.jpg", {st_mode=S_IFREG|0600, st_size=3392069, ...}) = 0 <1.406702>
17:35:26 openat(AT_FDCWD, "/home/jimis/Pictures/shotwell_import/2018/04/27/20180427_183406.jpg", O_RDONLY) = 18 <1.907845>
17:35:28 stat("/home/jimis/Pictures/shotwell_import/2018/04/27/20180427_183406.jpg", {st_mode=S_IFREG|0600, st_size=3392069, ...}) = 0 <1.419137>
17:35:30 openat(AT_FDCWD, "/home/jimis/Pictures/shotwell_import/2018/04/27/20180427_183406.jpg", O_RDONLY) = 18 <1.882576>
17:35:32 stat("/home/jimis/Pictures/shotwell_import/2018/04/27/20180427_183406.jpg", {st_mode=S_IFREG|0600, st_size=3392069, ...}) = 0 <1.389700>
17:35:33 openat(AT_FDCWD, "/home/jimis/Pictures/shotwell_import/2018/04/27/20180427_183406.jpg", O_RDONLY) = 18 <1.868621>
17:35:35 stat("/home/jimis/Pictures/shotwell_import/2018/04/27/20180427_183406.jpg", {st_mode=S_IFREG|0600, st_size=3392069, ...}) = 0 <1.403981>
17:35:36 stat("/home/jimis/Pictures/shotwell_import/2018/04/27/20180427_183406.jpg", {st_mode=S_IFREG|0600, st_size=3392069, ...}) = 0 <1.386416>
17:35:38 openat(AT_FDCWD, "/home/jimis/Pictures/shotwell_import/2018/04/27/20180427_183406.jpg", O_RDONLY) = 18 <1.870698>
Is it easy to identify which part of the code generates these identical system calls? Can they be reduced to one?
Version: Shotwell 0.30.1-c625f103 compiled from source.