I tried to profile darktable with valgrind/kcachegrind (just moving around in lighttable) and I’ve found that a lot of time was spent somewhere in liblcms2. darktablerc setting cache_color_managed sounds like it could be related, so I tried to disable it - I guess I can live without color managed thumbnails if that means better responsiveness. Indeed liblcms2 calls disappeared from the profiler output and it had some positive effect (roughly 25-30% faster expose), but unfortunately it’s still not enough to make lighttable feel comfortably fast:
With cache_color_managed=TRUE:
[lighttable] expose took 0,2752 sec
With cache_color_managed=FALSE:
[lighttable] expose took 0,1912 sec
The top kcachegrind calls (sorted by Self) now look like this:
Is anyone able to describe what exactly is done when one moves around lighttable? From a layman’s point of view it seems like dt does a whole lot of processing for what appears like highliting a differnt thumbnail and displaying its metadata. But I understand it may need to do a lot of “invisible” things.