On Sat, Nov 12, 2016 at 12:39 AM, <junkyardspar...@yepmail.net> wrote: > > > On Fri, Nov 11, 2016, at 06:23, Roman Lebedev wrote: > >> I would make a educated guess that at some point the darkroom caches, >> which usually are there and make darkroom fast, are invalidated for >> valid reasons, so darktable has to re-run the whole pipe, and not just >> one module. >> And as you can guess, the total pipe processing time is more than just the >> time >> of one of the modules... > > Ok, to illustrate how extreme the difference is, here's the perf data for > doing the exact same thing in 2.0.7 and 2.2~rc0, essentially having only lens > correction and denoise in the history stack while moving the viewed section > of 1:1 image around to random spots via the thumbnail. Same file, same > settings (other than anything that the new version changes when importing > settings from an older version), no OpenCL. The last entry for the 2.2 log > was an astonishing 49 seconds! That was an outlier, but there were several > between 20-30 seconds, and even the shortest times were notably slower than > the fairly consistent and short ones in 2.0.7. If this isn't a bug, it's > probably unlikely to be considered an enhancement by most users. ;)
Hm, so the speed decrease is for the full pipe, which is for main darkroom view. I expected to see a problem in preview pipe. How did you get darktable? What does this say (for 2.2.0rc0): $ grep codepath ~/.config/darktable/darktablerc Also, please show me whole darktable output when you just start it and then close it, without any -d options. > -- > jys Roman. ____________________________________________________________________________ darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
