Version: 1.9.0 (using KDE 4.6.4) OS: Linux I select 120 images and move them to a different folder on the _same_ partition. * 0.5 s when done in dolphin * 60 s when done in digikam Half a second for one image? This is quite some time. I also wait 5 s when moving 10 images. Why is this? I'm on a Core2Duo 3.16 GHz, Samsung F4 EG (2 TB). Reproducible: Always Steps to Reproduce: Move files. Expected Results: ... OS: Linux (x86_64) release 2.6.39-2.slh.1-aptosid-amd64 Compiler: gcc
There is no reason for that. In both case, KDE KIOSlave are used in background... Also, it's not reproducible on my computer (digiKam 2.0.0 RC) Gilles Caulier
I'll test again when 2.0 is out. Cannot explain it either; it is the same when renaming or deleting pictures as well. Is it maybe related to thumbnail generation which digikam tries to run at the same time? I just noticed that the first few images are renamed very quickly, then it again takes 0.5 s per image (and the album view constantly changes).
If it's the case, it's abnormal. Thumbs are generated in a separated thread, it don't must slowdown GUI. Here it's not the case (single our double core computer) Run kdebugdialog and turn on digiKam debug space including kioslave and kexiv2 and kdcraw. run digiKam in a console and look trace. Also, which image format you use ? JPEG or RAW ? Gilles Caulier
Created attachment 61665 [details] Moving files: Debug output log Moved around 50 files. Hope the log is useful.
And, the images were JPG usually.
At each file moved, KDE API fired an event through KDirWatch to brind digiKam database about new file to parse and registered. It can take a while. This can explain the difference with Dolphin. On my computer (double core), the difference is not too big. At least, it take more time, sure, but it's not like in your computer. But i'm use digiKam 2.0.0 RC. We probably improve this behavior (more than one year of development). If you can, please try this version on your computer. Thanks in advance Gilles Caulier
I also often have the feeling that digikam writes to the database after each step it takes. E.g. if one has a folder of new images. Instead of first reading all thumbnails and displaying them. It feels like digikam writes the thumbnail to the database/hdd after each picture – which of course slows the displaying of the thumbnails down.
Simon: Is significant CPU usage involved for any process? Sven: Yes, it writes each newly generated thumbnail to db immediately. (one time ever per picture). Of course, SQlite is very slow with a write operation. Here MySQL will be superior.
Simon, Do you see comment #8 from Marcel ? Gilles Caulier
Do you use mysql or sqlite database ? Gilles Caulier
We need a fresh feedback using last digiKam 4.2.0 Gilles Caulier
Can only test on 3.5 right now. Would this help as well?
It's better than nothing. But last stable 4.2.0 is out and it will be better to switch to 4.x series, where a lots of bugs have been fixed. Gilles Caulier
Simon, Any feedback ? Gilles Caulier
With 5.0.0, we drop KIOSlave and replace DB access to a pure multi-threaded interface, which is more faster and efficient. We have also drop the KDirWatch API in favor of QFileSystemWatcher. This king of problem with 5.0.0 is not reproducible with SQlite database. I close this file now. Gilles Caulier