[Digikam-devel] 0.10.0 too slow to use
jasper at treshna.com
Wed Jan 23 00:46:38 GMT 2008
> 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:
The slowness on startup is waiting for KDirWatch to finish setting up
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
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)
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.
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
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?
More information about the Digikam-devel