Loading thumbnails

Software ART
1

I noticed a significant change in the last weeks on how ART is loading (raw) thumbnails in a specific directory with 135 raw files (DNG).
While ART is showing the first thumbnails after 10 seconds it finished it up after 47 seconds in total. ART was reading out of the cache as I opened the directory before.
So I cranked up my compiled RT version and had a look how long it would take to load the same thumbnails. There were loaded completely after 5 seconds.
I know ART was once at least as good as RT in loading the thumbnails. I guess something has changed in the meantime. Is it possible to go back to the old performance?
ART-details:
Version: 1.8.4-1-g1469a0a82
Branch: master
Commit: 1469a0a82
Commit date: 2021-04-07
Compiler: cc 11.0.1
Processor: x86_64
System: Linux
Bit depth: 64 bits
Gtkmm: V3.24.4
Lensfun: V0.3.2.0
Exiv2: V0.27.3
LCMS2: V2.12
Build type: Release
Build flags: -std=c++11 -march=native -Werror=unused-label -fno-math-errno -Wall -Wuninitialized -Wno-deprecated-declarations -Wno-unused-result -fopenmp -Werror=unknown-pragmas -O3 -DNDEBUG -fno-tree-loop-vectorize -ftree-vectorize
Link flags: -march=native
OpenMP support: ON
MMAP support: OFF
Build OS: Linux
Build date: 2021-04-08T09:12:07Z

RT:
Version: 5.8-2840-g2eaccc40a
Branch: dev
Commit: 2eaccc40a
Commit date: 2021-04-08
Compiler: cc 11.0.0
Processor: x86_64
System: Linux
Bit depth: 64 bits
Gtkmm: V3.24.4
Lensfun: V0.3.2.0
Build type: Release
Build flags: -std=c++11 -march=native -Werror=unused-label -Werror=delete-incomplete -fno-math-errno -Wno-attributes -flto -Wall -Wuninitialized -Wcast-qual -Wno-deprecated-declarations -Wno-unused-result -Wunused-macros -fopenmp -Werror=unknown-pragmas -O3 -DNDEBUG -fno-tree-loop-vectorize -O3
Link flags: -march=native -flto
OpenMP support: ON
MMAP support: ON
Build OS: Linux 5.12.0-0.rc6.184.fc35.x86_64 x86_64
Build date: Fri, 09 Apr 2021 06:23:47 +0000 UTC
Build epoch: 1617949427
Build UUID: 32ca21f9-943e-4586-9515-136bb31b25bb

2

Hi,

I’ve just added an option to specify the number of threads for updating thumbnails (Preferences → Performance), you can try playing with it and see if it helps…

3

That was quick, thank you :handshake:
I just did a git pull and compiled a new release version.
After browsing through the folders I can confirm that the thumbnails get loaded very quickly now when available in cache. If not in cache, my impression is that the loading time is slightly (just a little bit) better than before. In any case the previous behavior (weeks ago) was way faster.
Btw, I noticed that the loading thumbnail progress bar doesn’t get updated while the thumbnails are processing.

20210412
202104121600×311 71.4 KB

4

Hi,

Quite possibly, but the program was basically unresponsive during the process. Now, you should be able to start working while thumbnails keep loading in the background. There’s no going back to the previous behaviour, or at least no interest in doing that from me, sorry…

In fact, I think I should get rid of that message altogether. Thumbnail loading is done in a more “on-demand” way now (or at least that is the intention), so the progress bar doesn’t make much sense imho