Bug 146557

Summary:	kio_digikamdate takes the cpu load up when downloading raw files with digikam
Product:	[Applications] digikam	Reporter:	Simon Oosthoek <kdebugs>
Component:	Database-Albums	Assignee:	Digikam Developers <digikam-bugs-null>
Status:	RESOLVED FIXED
Severity:	normal	CC:	caulier.gilles, unsecure, xendistar, zacktesting
Priority:	NOR
Version:	2.8.0
Target Milestone:	---
Platform:	Ubuntu
OS:	Linux
Latest Commit:		Version Fixed In:	5.0.0
Sentry Crash Report:

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!