ART 1.16-2.
I’m trying to browse a directory with 3000 files: 1400 images + 1400 xmps + 200 miscellaneous files. I took over 1 hour (about 1hr10mn) to be able to browse the directory.
CPU running 100%.
Anything I can do to speed it up?
$ inxi
CPU: 8-Core AMD Ryzen 7 4700U with Radeon Graphics (-MCP-) speed/min/max: 4191/1400/2000 MHz
Kernel: 5.10.0-17-amd64 x86_64 Up: 1h 16m Mem: 1793.2/15436.4 MiB (11.6%)
Storage: 4.1 TiB (47.9% used) Procs: 205 Shell: Bash inxi: 3.3.01 Thanks
Interesting. When you say “browse the directory” takes you over an hour, I’m not quite clear what you’re describing. Do you mean doing an initial read and constructing thumbnails for the first time? Something else?
For comparison: I’m running ART 1.16.2 with only the bottom of those 2 checkboxes (that @agriggio highlighted above) ticked on. I’ve got about 50,000 files that I access on an external SDD drive (internally installed, so not through a USB port). …but I’m not experiencing anything at all like the lag you’re experiencing. It takes a matter of seconds, not even minutes, for me to view any image I wish throughout my directory structure on this drive.
FYI: My computer is a Dell Optiplex 7010, i.e., roughly 10 years old (estimate) - salvaged from an office that was giving them away when upgrading their old hardware. I wiped it and am running Manjaro/Arch Linux on a single boot basis.
In short, I suspect you are having read/write related issues with your storage and/or serious CPU performance issues of some sort that would not seem to be related to ART’s performance in particular.
Do you have drive reading issues with other file-intensive software activities, or is this uniquely an ART issue for you?
My delay update was off, but my cached images was set to 2.
Thanks
One, I obviously didn’t explain myself clearly. The real slowdown is during the build of thumbnails (only 1400) to a samsung ssd that is pretty fast.
After that, open the directory when the thumbnails are already build is fast enough for me.
I’m using debian 11 bullseye which is faster for me (my work) than manjaro. I tested for some python scripts that I use to compile stuff and debian is between 40% and 50% faster for my stuff than manjaro.
It’s not art, no problem except when building the thumbnails.
Hi,
So did you find a combination that solves your problem? If not, can you share some more details? E.g. where do the xmps come from, and whether the images already had an arp sidecar but were not in the cache, or they had never been processed before…
Thanks!
No, I have not. Not yet. This weekend I expect to open a much, much larger directory (over the weekend because if it takes too much time…).
I use digikam for my dam. The xmps comes from digikam. There is no arp (yet, I was searching for a couple of old images.)
The images have never been processed before.
Could it be related to the xmps, with art trying to read/process the sidecars?
Thanks
Could be that, it’s not a configuration I use normally tbh. I’ll see if I can reproduce
FWIW, that is the configuration I’m using (i.e., import from camera SD card via digiKam, which creates xmp sidecars). Then I open the folder on my SSD in ART, which creates arp files as you can explain better than anyone 
Again, I’m not experiencing any meaningful lag in using ART’s file browser to view/load images having relied upon digiKam for import/sidecar creation. I would be surprised if that combination of apps is causing @foto’s sluggish load issue. HTH.
This is not sluggish, slugs zooms by…
This is molasses… 
Thanks
Ha! Weird indeed.
And just to confirm, there are no other file reading/loading operations in other applications that respond poorly? Ideally, perhaps you have another RAW-processing app installed you can compare similar operational performance with? If so, it might help diagnose the source of this behavior.
I just ran art to open another larger directory to browse photos: 7084 files:
It took only 6 mn + a few seconds
Changes done:
Hope this will help somebody else too.
Thanks for the info. I still cannot reproduce this, but maybe someone else will… what happens if you try to set “max threads for updating thumbnails” to 1 in the preferences?
Just tried over the weekend.
Summary
I didn’t see a difference by setting the max threads thumbnails to 1 with the default of 0.
The one that significantly improved the situation was: delay of update of thumbnails while opening directories.
Thanks
Could it then be that those miscellaneous files slowed it down, or have I missed something in the thread? What type of were those files?
Either you missed something or I didn’t express myself properly (which happens far more often than I’d care to admit).
I wanted to stress that there was no other file, just images files + their xmps (contrarily to the 1st post with another directory).
Hm, what I mean, in your 1st post there were 1400 photos and 200 misc files, and it took more than an hour. Now you have 3500 photos and no misc files, and it took only 6 minutes?
Different directory, different photos and different number of files.
