lots of photos and startup time

[Chris Green]

On Thu, Jul 09, 2009 at 12:16:08PM +0200, Daniel Bauer wrote:

> On Thursday 09 July 2009 10:37:13, Andi Clemens wrote:
> > ...
> >
> > Daniel,
> > how many items  / images do you have in your database?
> > In my current test collection, I have 200.000, but my database is only
> > 180MB big.
> >
> > Maybe yours is really corrupted (or has a lot of old entries, that you
> > might need to delete manually).
> >
> > If you have less images, you could try to remove all entries from the table
> > "images" that have a status of 3 (deleted).
>
> Hi Andi,
>
> As I cleaned up my laptop last week there are now only the actual 9086 image
> files in digikam. The db file is 1.6 MB. But please keep in mind that I still
> use digikam 0.9.3.
>
> However, after a reboot, starting digikam takes 66 seconds until the splash
> screen appears and then another 10 seconds to appear the album.
>
> At home (with many, many more images) it takes much longer, so that I start it
> and then go and have a coffee. This applies only to the *first* start of
> digikam, later starts are much faster.
>
> I also have a kde4-digikam 0.10.0.The splash screen appeard immediately - and
> styed there for 28 Minutes untill  I killed the process, renamed digikam4.db
> and restartet 0.10.0.. It shows me that it imports/updates the database...
> After 21 minutes it's is finally here.... One reason I decided to stay with
> the old version....
>
> The new digikam4.db is 4.5 MB.
>
> in the 0.9.3 images table there is no field called "status"...
>

I have something over 20000 images in my digikam and the digikam4.db
is something like 17Mb.  I've just moved to xubuntu 9.04 which has
digikam version 0.10.0.

Starting up the *first* time in xubuntu 9.04 took a minute or so (I
didn't time it), starting up subsequently, even on a clean, just
rebooted, system takes around ten seconds.

This is on an Intel quad core based system with (if I remember right)
8Gb of memory.

--
Chris Green

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Gilles Caulier-4]

And which FS to host DB and collections (can be differents)

Gilles

2009/7/9 Chris G <[hidden email]>:

> On Thu, Jul 09, 2009 at 12:16:08PM +0200, Daniel Bauer wrote:
>> On Thursday 09 July 2009 10:37:13, Andi Clemens wrote:
>> > ...
>> >
>> > Daniel,
>> > how many items  / images do you have in your database?
>> > In my current test collection, I have 200.000, but my database is only
>> > 180MB big.
>> >
>> > Maybe yours is really corrupted (or has a lot of old entries, that you
>> > might need to delete manually).
>> >
>> > If you have less images, you could try to remove all entries from the table
>> > "images" that have a status of 3 (deleted).
>>
>> Hi Andi,
>>
>> As I cleaned up my laptop last week there are now only the actual 9086 image
>> files in digikam. The db file is 1.6 MB. But please keep in mind that I still
>> use digikam 0.9.3.
>>
>> However, after a reboot, starting digikam takes 66 seconds until the splash
>> screen appears and then another 10 seconds to appear the album.
>>
>> At home (with many, many more images) it takes much longer, so that I start it
>> and then go and have a coffee. This applies only to the *first* start of
>> digikam, later starts are much faster.
>>
>> I also have a kde4-digikam 0.10.0.The splash screen appeard immediately - and
>> styed there for 28 Minutes untill  I killed the process, renamed digikam4.db
>> and restartet 0.10.0.. It shows me that it imports/updates the database...
>> After 21 minutes it's is finally here.... One reason I decided to stay with
>> the old version....
>>
>> The new digikam4.db is 4.5 MB.
>>
>> in the 0.9.3 images table there is no field called "status"...
>>
> I have something over 20000 images in my digikam and the digikam4.db
> is something like 17Mb.  I've just moved to xubuntu 9.04 which has
> digikam version 0.10.0.
>
> Starting up the *first* time in xubuntu 9.04 took a minute or so (I
> didn't time it), starting up subsequently, even on a clean, just
> rebooted, system takes around ten seconds.
>
> This is on an Intel quad core based system with (if I remember right)
> 8Gb of memory.
>
> --
> Chris Green
>
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users
>

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Chris Green]

On Thu, Jul 09, 2009 at 12:33:59PM +0200, Gilles Caulier wrote:

>
> 2009/7/9 Chris G <[hidden email]>:
> > On Thu, Jul 09, 2009 at 12:16:08PM +0200, Daniel Bauer wrote:
> >> On Thursday 09 July 2009 10:37:13, Andi Clemens wrote:
> >> > ...
> >> >
> >> > Daniel,
> >> > how many items  / images do you have in your database?
> >> > In my current test collection, I have 200.000, but my database is only
> >> > 180MB big.
> >> >
> >> > Maybe yours is really corrupted (or has a lot of old entries, that you
> >> > might need to delete manually).
> >> >
> >> > If you have less images, you could try to remove all entries from the table
> >> > "images" that have a status of 3 (deleted).
> >>
> >> Hi Andi,
> >>
> >> As I cleaned up my laptop last week there are now only the actual 9086 image
> >> files in digikam. The db file is 1.6 MB. But please keep in mind that I still
> >> use digikam 0.9.3.
> >>
> >> However, after a reboot, starting digikam takes 66 seconds until the splash
> >> screen appears and then another 10 seconds to appear the album.
> >>
> >> At home (with many, many more images) it takes much longer, so that I start it
> >> and then go and have a coffee. This applies only to the *first* start of
> >> digikam, later starts are much faster.
> >>
> >> I also have a kde4-digikam 0.10.0.The splash screen appeard immediately - and
> >> styed there for 28 Minutes untill  I killed the process, renamed digikam4.db
> >> and restartet 0.10.0.. It shows me that it imports/updates the database...
> >> After 21 minutes it's is finally here.... One reason I decided to stay with
> >> the old version....
> >>
> >> The new digikam4.db is 4.5 MB.
> >>
> >> in the 0.9.3 images table there is no field called "status"...
> >>
> > I have something over 20000 images in my digikam and the digikam4.db
> > is something like 17Mb.  I've just moved to xubuntu 9.04 which has
> > digikam version 0.10.0.
> >
> > Starting up the *first* time in xubuntu 9.04 took a minute or so (I
> > didn't time it), starting up subsequently, even on a clean, just
> > rebooted, system takes around ten seconds.
> >
> > This is on an Intel quad core based system with (if I remember right)
> > 8Gb of memory.
> >
> And which FS to host DB and collections (can be differents)
>

It's all EXT3 on a single local disk.

    /dev/sdb1 on /home type ext3 (rw,relatime)

--
Chris Green

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Marcel Wiesweg]

I think we should clarify some points:

1) It is _not_ normal that digikam needs longer than about 1sec per 10000
images to startup (on a modern machine)
2) we are not talking about the very first startup which includes a full
collection scan, reading the metadata of every single files. Let's say this
can take 1min / 10.000. (there is still a major problem with JPEG2000 images,
so excluding them)
2) For KDE4, there is the problem of KDirWatch stat'ing every single file,
which may explain a short delay (the mentioned 2 secs)
3) The scan at startup, with no modification, can probably be emulated by
"ls":
time ls -Rl /media/fotos/ | wc -l
Here, about 1sec / 10.000
Emulating db access at startup is more difficult
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Gilles Caulier-4]

2009/7/9 Marcel Wiesweg <[hidden email]>:

> I think we should clarify some points:
>
> 1) It is _not_ normal that digikam needs longer than about 1sec per 10000
> images to startup (on a modern machine)
> 2) we are not talking about the very first startup which includes a full
> collection scan, reading the metadata of every single files. Let's say this
> can take 1min / 10.000. (there is still a major problem with JPEG2000 images,
> so excluding them)
> 2) For KDE4, there is the problem of KDirWatch stat'ing every single file,
> which may explain a short delay (the mentioned 2 secs)
> 3) The scan at startup, with no modification, can probably be emulated by
> "ls":
> time ls -Rl /media/fotos/ | wc -l
> Here, about 1sec / 10.000
> Emulating db access at startup is more difficult

Perhaps it's easy to disable all DB queries at startup and lets only
FS access, and after compare with normal code to see how many time DB
access on startup is...

gilles
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Milan Knížek]

Milan Knížek píše v Út 07. 07. 2009 v 23:22 +0200:

> Andi Clemens píše v Út 07. 07. 2009 v 13:12 +0200:
> > Hmm seems to be a reiserFS problem, since every one reporting this is using
> > reiserFS, also the older reports are talking about reiser.
> >
> Yes, it could be reiserfs. Until recently (a week ago or so), I have
> been using ext3 [1] and did not notice such a long startup.
>
> Now it takes about three minutes to load 15 thousand images (the splash
> screen shows "reading database") for the first run after PC reboot.
> Iotop shows average read activity 600 kB/s. (I have 4 GB RAM on amd64
> with digiKam 0.10.0, ubuntu.)
>
> If I quit digiKam and start again, it takes about 5 seconds....
>
> Flushing cache does not lead to expected long startup time - just about
> 13 seconds.
>

Despite wories about stability, I moved my desktop single filesystem
from reiser to ext4 (simply backup / restore & update grub + fstab).

Voila, digiKam starts in about 20 seconds (15 thousand images) after
reboot, subsequent starts are within 5 seconds.

regards,

Milan Knizek
knizek (dot) confy (at) volny (dot) cz
http://www.milan-knizek.net - About linux and photography (Czech
language only)

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Gilles Caulier-4]

2009/7/9 Milan Knížek <[hidden email]>:

> Milan Knížek píše v Út 07. 07. 2009 v 23:22 +0200:
>> Andi Clemens píše v Út 07. 07. 2009 v 13:12 +0200:
>> > Hmm seems to be a reiserFS problem, since every one reporting this is using
>> > reiserFS, also the older reports are talking about reiser.
>> >
>> Yes, it could be reiserfs. Until recently (a week ago or so), I have
>> been using ext3 [1] and did not notice such a long startup.
>>
>> Now it takes about three minutes to load 15 thousand images (the splash
>> screen shows "reading database") for the first run after PC reboot.
>> Iotop shows average read activity 600 kB/s. (I have 4 GB RAM on amd64
>> with digiKam 0.10.0, ubuntu.)
>>
>> If I quit digiKam and start again, it takes about 5 seconds....
>>
>> Flushing cache does not lead to expected long startup time - just about
>> 13 seconds.
>>
> Despite wories about stability, I moved my desktop single filesystem
> from reiser to ext4 (simply backup / restore & update grub + fstab).
>
> Voila, digiKam starts in about 20 seconds (15 thousand images) after
> reboot, subsequent starts are within 5 seconds.

Can you remember me the time with reiserfs ?

Gilles
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Milan Knížek]

Gilles Caulier píše v Čt 09. 07. 2009 v 19:24 +0200:

> 2009/7/9 Milan Knížek <[hidden email]>:
> > Milan Knížek píše v Út 07. 07. 2009 v 23:22 +0200:
> >> Andi Clemens píše v Út 07. 07. 2009 v 13:12 +0200:
> >> > Hmm seems to be a reiserFS problem, since every one reporting this is using
> >> > reiserFS, also the older reports are talking about reiser.
> >> >
> >> Yes, it could be reiserfs. Until recently (a week ago or so), I have
> >> been using ext3 [1] and did not notice such a long startup.
> >>
> >> Now it takes about three minutes to load 15 thousand images (the splash
> >> screen shows "reading database") for the first run after PC reboot.
> >> Iotop shows average read activity 600 kB/s. (I have 4 GB RAM on amd64
> >> with digiKam 0.10.0, ubuntu.)
> >>
> >> If I quit digiKam and start again, it takes about 5 seconds....
> >>
> >> Flushing cache does not lead to expected long startup time - just about
> >> 13 seconds.
> >>
> > Despite wories about stability, I moved my desktop single filesystem
> > from reiser to ext4 (simply backup / restore & update grub + fstab).
> >
> > Voila, digiKam starts in about 20 seconds (15 thousand images) after
> > reboot, subsequent starts are within 5 seconds.
>
> Can you remember me the time with reiserfs ?
>

Yes, it is actually written above - the previous email I commented was
from me.

To repeat: about 3 minutes start up time after reboot with reiserfs and
quite stable 600 kB/s disk read activity.

With ext4, the disk read was varying between 3 - 13 MB/s. Also, the
startup time is slowlier for me, since Qt/KDE libraries must load (I use
Gnome).

The dikikam4.db is 53 MB big.


A side note:
Suprisingly, digiKam lost the information about the local album location
(Album folder was empty, no images displayed). However, the database was
loaded - all tags available, time-line showing number of images. This
should not happen, I have used rsync -av to backup and restore, the only
things which probably changed were the partition UUID and underlying
filesystem.

In the Settings / Collections there was "Images" shown under local
collections, but the path information was empty. Removing this
collection and adding back (media/Data/Photo/Images) resulted in
scanning all images again and now things seem to work as expected.

regards,

Milan Knizek
knizek (dot) confy (at) volny (dot) cz
http://www.milan-knizek.net - About linux and photography (Czech
language only)

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

On Wednesday 08 July 2009 12:53:37 Jacek Poplawski wrote:

> On Wed, Jul 8, 2009 at 10:43 AM, Andi Clemens <[hidden email]> wrote:
> > Then your system is broken, this is really not normal.
> > Even with reiserFS I had never such bad startup times.
> > Not even 5 Minutes.
>
> So you assume that my system is broken too?
>
> > DB access has been improved already and this is not what slows down the
> > startup so much, we don't query a lot during the application starts.
>
> I also see database loading on splash screen during all these minutes of
> loading.
>
> Are there any debug logs I could enable to give you some more details?
> Or could you tell me where in code I could measure time, so I could show
> you values (I am a programmer)?

What are messages from console when starting digiKam? It may be interesting
because Marble when starting precisely tells how much time everything takes
time - maybe this is not digiKam fault at all?

m.
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Gilles Caulier-4]

It's very simple to check if marble slow down digiKam start-up : just
recompile digiKam without marble support. Uninstall libmarblewidget
before.

Gilles

2009/7/9 Mikolaj Machowski <[hidden email]>:

> On Wednesday 08 July 2009 12:53:37 Jacek Poplawski wrote:
>> On Wed, Jul 8, 2009 at 10:43 AM, Andi Clemens <[hidden email]> wrote:
>> > Then your system is broken, this is really not normal.
>> > Even with reiserFS I had never such bad startup times.
>> > Not even 5 Minutes.
>>
>> So you assume that my system is broken too?
>>
>> > DB access has been improved already and this is not what slows down the
>> > startup so much, we don't query a lot during the application starts.
>>
>> I also see database loading on splash screen during all these minutes of
>> loading.
>>
>> Are there any debug logs I could enable to give you some more details?
>> Or could you tell me where in code I could measure time, so I could show
>> you values (I am a programmer)?
>
> What are messages from console when starting digiKam? It may be interesting
> because Marble when starting precisely tells how much time everything takes
> time - maybe this is not digiKam fault at all?
>
> m.
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users
>

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

On Friday 10 July 2009 07:58:51 Gilles Caulier wrote:
> It's very simple to check if marble slow down digiKam start-up : just
> recompile digiKam without marble support. Uninstall libmarblewidget
> before.
>

I did tests some time ago and for me - I don't have problems with start -  
startup of Marble widget takes about half of the time necessary for whole
digiKam.

m.
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

On Friday 10 July 2009 18:27:39 Mikolaj Machowski wrote:
> I did tests some time ago and for me - I don't have problems with start -
> startup of Marble widget takes about half of the time necessary for whole
> digiKam.

This sounds a lot - can we somehow delay loading of Marble to a later time
(when user actually uses the widget)?

Regards,
Luka
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

We could also improve the speed by loading the imageplugins only when the
editor is opened for the first time.
All the plugins (kipi and image) could be loaded while digiKam is already
showing the interface. This wouldn't make the actual loading faster, but it
looks faster to the user.

Andi

On Friday 10 July 2009 19:18:55 Luka Renko wrote:

> On Friday 10 July 2009 18:27:39 Mikolaj Machowski wrote:
> > I did tests some time ago and for me - I don't have problems with start -
> > startup of Marble widget takes about half of the time necessary for whole
> > digiKam.
>
> This sounds a lot - can we somehow delay loading of Marble to a later time
> (when user actually uses the widget)?
>
> Regards,
> Luka
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

Also for me marble startup is not the bottleneck, looking at a lot of
callgrind profiles it is (for me) the loading of the plugins (48% of the time)
and the scanning (39%). The rest is setting up the UI.

Andi

On Friday 10 July 2009 19:27:48 Andi Clemens wrote:

> We could also improve the speed by loading the imageplugins only when the
> editor is opened for the first time.
> All the plugins (kipi and image) could be loaded while digiKam is already
> showing the interface. This wouldn't make the actual loading faster, but it
> looks faster to the user.
>
> Andi
>
> On Friday 10 July 2009 19:18:55 Luka Renko wrote:
> > On Friday 10 July 2009 18:27:39 Mikolaj Machowski wrote:
> > > I did tests some time ago and for me - I don't have problems with start
> > > - startup of Marble widget takes about half of the time necessary for
> > > whole digiKam.
> >
> > This sounds a lot - can we somehow delay loading of Marble to a later
> > time (when user actually uses the widget)?
> >
> > Regards,
> > Luka
> > _______________________________________________
> > Digikam-users mailing list
> > [hidden email]
> > https://mail.kde.org/mailman/listinfo/digikam-users
>
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

On Friday 10 July 2009 19:31:44 Andi Clemens wrote:
> Also for me marble startup is not the bottleneck, looking at a lot of
> callgrind profiles it is (for me) the loading of the plugins (48% of the
> time) and the scanning (39%). The rest is setting up the UI.

That sounds like a lot - since plugins are not optional anymore (or shipped
separately), it sounds that this could be simplified all together. I suspect
reading .desktop files and stuff is what is making it slow, correct?

Regards,
Luka
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

For all of you with long startup times:
You might want to try to defrag the folder where your images are located.
There are some filesystem independent tools (defrag, shake, fidefrag...).

If you do so, please report back to the mailinglist.

Andi

On Tuesday 07 July 2009 11:37:54 Jacek Poplawski wrote:

> Hello,
>
> I use Digikam to organize my photo collection and manage all the photos,
> the main problem is startup time. I have more than 20.000 photos on disk.
> Well in fact I have even more if I include archives from last years. But I
> put only these 20.000 in Digikam collections.
>
> When I start Digikam it takes _minutes_, if I just want to find one single
> photo I need to wait few minutes first. Or use different application like
> geeqie (I store photos as RAW files, but geeqie knows how to show them).
>
> I disabled checking for new files at startup but still it takes lots of
> time to just read the database.
> Picasa doesn't have this problem.
>
> Is it a bug? Should I just put less files in Digikam collections and
> organize them by file manager instead Digikam?

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

I tested this startup issue again and these are my results for a 50.000 images
collection:

1. MarbleWidget: 6s
2. Database Scan: 13s

I disabled MarbleWidget and tested it again, yes it is faster.
To measure the startup time, you need to always drop the disk caches,
otherwise the results are useless. As root:

sync
echo 1 > /proc/sys/vm/drop_caches

I then moved the AlbumManager::startScan() into a slot, that is called 100ms
after the DigikamApp constructor has been run.

This way it feels faster, the only drawback now is that the app appears empty,
and the images begin to fly in.
Still much better than waiting over 22 seconds for digiKam to appear.

I guess the best would be to have album scanning in its own thread, so that
scanning can be started while DigikamApp() is running through.

Is this possible? Can we run this in a separate thread?

I will attach the patch to this mail, so you can test it. On smaller
collections it works fine, on bigger a thread might be a good solution.

Andi

On Tuesday 07 July 2009 11:37:54 Jacek Poplawski wrote:

> Hello,
>
> I use Digikam to organize my photo collection and manage all the photos,
> the main problem is startup time. I have more than 20.000 photos on disk.
> Well in fact I have even more if I include archives from last years. But I
> put only these 20.000 in Digikam collections.
>
> When I start Digikam it takes _minutes_, if I just want to find one single
> photo I need to wait few minutes first. Or use different application like
> geeqie (I store photos as RAW files, but geeqie knows how to show them).
>
> I disabled checking for new files at startup but still it takes lots of
> time to just read the database.
> Picasa doesn't have this problem.
>
> Is it a bug? Should I just put less files in Digikam collections and
> organize them by file manager instead Digikam?

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

Here is the little patch...

Andi

On Wednesday 12 August 2009 11:35:49 Andi Clemens wrote:

> I tested this startup issue again and these are my results for a 50.000
> images collection:
>
> 1. MarbleWidget: 6s
> 2. Database Scan: 13s
>
> I disabled MarbleWidget and tested it again, yes it is faster.
> To measure the startup time, you need to always drop the disk caches,
> otherwise the results are useless. As root:
>
> sync
> echo 1 > /proc/sys/vm/drop_caches
>
> I then moved the AlbumManager::startScan() into a slot, that is called
> 100ms after the DigikamApp constructor has been run.
>
> This way it feels faster, the only drawback now is that the app appears
> empty, and the images begin to fly in.
> Still much better than waiting over 22 seconds for digiKam to appear.
>
> I guess the best would be to have album scanning in its own thread, so that
> scanning can be started while DigikamApp() is running through.
>
> Is this possible? Can we run this in a separate thread?
>
> I will attach the patch to this mail, so you can test it. On smaller
> collections it works fine, on bigger a thread might be a good solution.
>
> Andi
>
> On Tuesday 07 July 2009 11:37:54 Jacek Poplawski wrote:
> > Hello,
> >
> > I use Digikam to organize my photo collection and manage all the photos,
> > the main problem is startup time. I have more than 20.000 photos on disk.
> > Well in fact I have even more if I include archives from last years. But
> > I put only these 20.000 in Digikam collections.
> >
> > When I start Digikam it takes _minutes_, if I just want to find one
> > single photo I need to wait few minutes first. Or use different
> > application like geeqie (I store photos as RAW files, but geeqie knows
> > how to show them).
> >
> > I disabled checking for new files at startup but still it takes lots of
> > time to just read the database.
> > Picasa doesn't have this problem.
> >
> > Is it a bug? Should I just put less files in Digikam collections and
> > organize them by file manager instead Digikam?
>
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

Ok I found one issue with that approach: somehow AdvancedSlideshow will be
disabled, but all the other kipi-plugins seem to work. I guess this indicates
a problem with the plugin itself....?

Andi

On Wednesday 12 August 2009 11:37:38 Andi Clemens wrote:

> Here is the little patch...
>
> Andi
>
> On Wednesday 12 August 2009 11:35:49 Andi Clemens wrote:
> > I tested this startup issue again and these are my results for a 50.000
> > images collection:
> >
> > 1. MarbleWidget: 6s
> > 2. Database Scan: 13s
> >
> > I disabled MarbleWidget and tested it again, yes it is faster.
> > To measure the startup time, you need to always drop the disk caches,
> > otherwise the results are useless. As root:
> >
> > sync
> > echo 1 > /proc/sys/vm/drop_caches
> >
> > I then moved the AlbumManager::startScan() into a slot, that is called
> > 100ms after the DigikamApp constructor has been run.
> >
> > This way it feels faster, the only drawback now is that the app appears
> > empty, and the images begin to fly in.
> > Still much better than waiting over 22 seconds for digiKam to appear.
> >
> > I guess the best would be to have album scanning in its own thread, so
> > that scanning can be started while DigikamApp() is running through.
> >
> > Is this possible? Can we run this in a separate thread?
> >
> > I will attach the patch to this mail, so you can test it. On smaller
> > collections it works fine, on bigger a thread might be a good solution.
> >
> > Andi
> >
> > On Tuesday 07 July 2009 11:37:54 Jacek Poplawski wrote:
> > > Hello,
> > >
> > > I use Digikam to organize my photo collection and manage all the
> > > photos, the main problem is startup time. I have more than 20.000
> > > photos on disk. Well in fact I have even more if I include archives
> > > from last years. But I put only these 20.000 in Digikam collections.
> > >
> > > When I start Digikam it takes _minutes_, if I just want to find one
> > > single photo I need to wait few minutes first. Or use different
> > > application like geeqie (I store photos as RAW files, but geeqie knows
> > > how to show them).
> > >
> > > I disabled checking for new files at startup but still it takes lots of
> > > time to just read the database.
> > > Picasa doesn't have this problem.
> > >
> > > Is it a bug? Should I just put less files in Digikam collections and
> > > organize them by file manager instead Digikam?
> >
> > _______________________________________________
> > Digikam-users mailing list
> > [hidden email]
> > https://mail.kde.org/mailman/listinfo/digikam-users

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Marcel Wiesweg]

> I guess the best would be to have album scanning in its own thread, so that
> scanning can be started while DigikamApp() is running through.
>
> Is this possible? Can we run this in a separate thread?

AlbumManager is not thread-safe.
But I suspect the real problem is adding the KDirWatches? Is it faster
removing line 1050,
      d->dirWatch->addDir(location.albumRootPath(), KDirWatch::WatchSubDirs);
?
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users