[Digikam-devel] 0.10.0 too slow to use

[Arnd Baecker]

On Wed, 23 Jan 2008, Jasper Mackenzie wrote:

> > Well, hard to tell: Gilles had some ideas on the IRC yesterday:
> > - is the NFS server set up correctly?
> >  (presumably yes, if gqview works fine/fast ;-)
> > - do you have the database on the file server as well?
>   no, its stored locally in ~/.digikam-database
> > If not, there is no reason to have latency time.
> > - In general: there are many regression tests to be done:
> >  http://websvn.kde.org/trunk/extragear/graphics/digikam/KDE4PORT?revision=762166&view=markup
> The slowness on startup is waiting for KDirWatch to finish setting up
> watches.
>   I googled a bit to see if there was anyway to optimise nfs for inotify,
> and all I could find was that it seemed that inotify was not supported
> over nfs.
> It seemed also that fam was the prefered option, so I tried fam, and,
> well, after an hour I gave up waiting for it to complete setting up
> watches. (fam from gamin, both client and server)

My impression is: in order to investigate this
you need to write a small test programm which
calls KDirWatch. Then you have to compare the timings for
local and NFS usage and with this information you could
ask the guys responsible for KDirWatch for their advice
(of course you could ask them without these tests ;-).
It really seems to be a problem of the underlying libraries.
If so, it would be really great if you could
track that down before 0.10 gets finalized ...

Googling I only came across this old, but still interesting post
http://lists.kde.org/?l=kde-devel&m=103860099310899&w=2
http://lists.kde.org/?l=kde-core-devel&m=104609291211449&w=2
and more recent:
http://www.progressive-comp.com/?l=kde-core-devel&m=118651187316302&w=2


> I tried to setup albums using samba, but it didnt seem to work at all.
> NFS has the advantage that if I take the HDD out of the servre and attach
> it as a USB drive, as long as its the same mount point, digikam should
> behave as before.
>   Which makes me think that taking this sort of thing into consideration
> may be of use. the idea thats coming to mind is something more like path
> indipendant albums, where the albums are recognised by directory
> structure, and digikam simply monitors a set of mount directories to see
> which albums are attached. i.e /media and /mnt
>   I guess this is in some sort of analogue to cddb, recognising cd's by
> track lengths etc.

Please check the bug tracker, I think something like
this has been discussed (I did not find it on a quick search though).

> There are other slownesses with image loading as compared to gqview, are
> these issues realted to the alphaness of 0.10.0 or greater mem/cpu
> requirements etc.

Well, for this you would have to compare 0.10 with 0.9.3
on your machine.
See also:
  https://bugs.kde.org/show_bug.cgi?id=132047

> I did notice that the 'kde4' process was using a heap of cpu/mem whilst
> using digikam. I am running digikam in a compiz/gnome environment...
>
> There does seem to be a higher cpu usage for nfsd on the server as
> compared to gqview doing similar things?

Maybe this is related to:
  https://bugs.kde.org/show_bug.cgi?id=150938

Best, Arnd