Bug 146557 - kio_digikamdate takes the cpu load up when downloading raw files with digikam
Summary: kio_digikamdate takes the cpu load up when downloading raw files with digikam
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Database-Albums (show other bugs)
Version: 2.8.0
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-06-08 21:40 UTC by Simon Oosthoek
Modified: 2017-07-25 10:41 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.0.0
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Simon Oosthoek 2007-06-08 21:40:59 UTC
Version:           0.9.1 (using KDE KDE 3.5.7)
Installed from:    Ubuntu Packages
OS:                Linux

While downloading a bunch (like 100) raw files from my CF card (not from the camera directly), I was doing something else and the system was very slow. It turned out that digikam was taking lots of CPU, but also spawning lots of CPU hogging kio_digikamdate processes. I don't know what this does, but it is a performance killer!

Please re-assign if this should be under kio...

Cheers

Simon
Comment 1 Benoit Courty 2008-05-27 22:19:36 UTC
I have the same issue with 0.9.3 in KDE4 when using ufraw from DigiKam, when ufraw export the jpg the CPU is half for kio and half for ufraw.
This double the time of jpg creation : 35 seconds on my XP3200+...
Comment 2 Thierry Florac 2008-06-26 22:56:45 UTC
I'm having the same problem.
I'm using Digikam-0.9.3 (KDE 3.5.9) on Debian GNU/Linux.
When adding, copying or removing a single small image (700 pixels width), CPU usage is going to 50% (I'm using a Dual Core CPU) for at least 15 seconds !!
Looking at "top", it seems that Digikam and kio_digikamdate are using the whole CPU, letting Digikam totally un-responsive...

My computer is quite recent : 3 GHz Core2 CPU with 2 Gb RAM, 160 and 320 Gb SATA disks ; my images (35.000 files) are stored on a RAID5 made of 3 * 500 Gb SATA2 disks in an SQLite database.
Comment 3 caulier.gilles 2008-06-26 23:41:09 UTC
Which version of sqlite you use ?

Which RAW file format ?

Gilles Caulier

Comment 4 caulier.gilles 2008-12-04 16:26:11 UTC
I have never reproduced this problem on my computers...

It still valid using last 0.9.4 (KDE3) or 0.10.0 (KDE4) ?

Gilles Caulier
Comment 5 Simon Oosthoek 2008-12-06 21:51:06 UTC
Yes, I think it's still valid on an early 0.9.5-svn version
Comment 6 caulier.gilles 2009-06-11 19:38:43 UTC
*** Bug 159377 has been marked as a duplicate of this bug. ***
Comment 7 caulier.gilles 2011-12-15 10:13:40 UTC
Simon,

This file still valid with digiKam 2.x serie ?

Gilles Caulier
Comment 8 Zack Evans 2013-02-01 15:08:29 UTC
Gilles, I have been restructuring my collections and I have noticed the same problem when moving across disks. 

Moves go a lot faster if I renice the main digikam process to reduce the contention with kio_digikamdate. It uses nearly the same CPU time during the move as digikam itself.
Comment 9 Zack Evans 2013-02-01 15:09:46 UTC
Whoops, I forgot to say version. 2.8.0-0ubuntu1.
Comment 10 caulier.gilles 2013-12-04 16:41:16 UTC
This file still valid using digiKam 3.5.0 ?

Gilles Caulier
Comment 11 Zack Evans 2014-07-14 22:02:01 UTC
I've had different weird slowness with imports on several versions recently - I'll do some proper troubleshooting and see if this problem is still there. Sometimes import is quick and sometimes it is slow. I have just installed 4.1...
Comment 12 caulier.gilles 2014-08-24 21:17:37 UTC
Zack,

Some fresh news here ? digiKam 4.2.0 have been released...

Gilles Caulier
Comment 13 caulier.gilles 2015-09-25 15:58:35 UTC
With next digiKam 5.0.0, all dedicated KIO-Slave are now dropped for a better portability and to be maintainable easily.

Now digiKam use a multi-core and multi-thread interface to query the database.

Gilles Caulier
Comment 14 unsecure 2015-09-28 18:40:03 UTC
very nice!