lots of photos and startup time

it is a little bit faster, but not much, maybe 1s overall.

Andi

On Wednesday 12 August 2009 19:23:05 Marcel Wiesweg wrote:

> > 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

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

[Marcel Wiesweg]

> it is a little bit faster, but not much, maybe 1s overall.

Callgrind clears things up a bit. Adding the KDirwatches accounts for only 14%
of cost in startScan(), 83% is caused by emitting signals about new albums, in
other words: Setting up the various album views. It's mostly tags here,
probably because I have much more TAlbums than PAlbum.
I am sure there is room for improvement, but I dont feel like doing anything
in that area before porting to model/view after 1.0 is out.

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