[Digikam-devel] [Bug 305359] Advanced rename of lots of images is slow

[Marcel Wiesweg]

https://bugs.kde.org/show_bug.cgi?id=305359

--- Comment #3 from Marcel Wiesweg <marcel.wiesweg at gmx.de> ---
Yes, by introducing delays...which is not good as changes are visible later.

The root of many problems is that any write operation to Sqlite triggers a call
to fsync(), which is very slow and the main bottleneck in this setup. This is a
principal problem. Newer development like Sqlite WAL are steps in the right
direction, but WAL in my experience does not solve the problem.
You can of course switch off the "atomic" mode for you db, but I didn't dare
doing this so far.

I've recently changed the ImageScanner optimizing around that problem so that
there is only one write-to-disk per changed file.

Regarding the problem at hand, we should check console output during the rename
operation, that for each file there's a "recognized as identical..." message
and the file is not actually rescanned.
We should check if the problem is CPU or harddisk, if it's CPU, confirm it is
the main digikam process. If it is, valgrind callgrind will be interesting.

-- 
You are receiving this mail because:
You are the assignee for the bug.