[KPhotoAlbum] Startup performance

[Martin Höller]

Hi!

On Oct.13.2020 Tobias Leupold wrote:

> Question is if really need to optimize things furtherly.

Fully ACK. I think with the recent optimisations KPA is quite fast anyway.

That said, I was just speaking out ideas that came to mind. No need to
implement it.

> Speaking of myself, I
> have a "normal"(?) "photos we take along the year and during vacation"
> database with about 12,000 photos. It resides on NFS, on my home LAN's NAS. On
> a classical hd. Which should be -- performance-wise -- the worst combination
> of all. Startup takes like one second though (or maybe one and a half ;-)

I'm a hobby photographer with little time, so I'm not taking a lot of
photos. But my first digital images go back to 2003 which leads to a
database with about 50k images. And with recent development of
smartphones, I guess people are taking more and more photos. So being fit
for future is always a good idea.

And BTW, I really think Robert enjoys pushing performance further ;-)

> On Dienstag, 13. Oktober 2020, 18:50:48 CEST schrieb Robert Krawitz:
> > One of the goals of KPA is for the database to be human readable and
> > editable.  Splitting up the image file in that way makes the structure more
> > complicated to move/copy and edit.

That's true and I didn't say it would be an easy job ;-)

Still, the format should stay almost the same and thus still be
readable/writable by humans. IMHO, if we consider splitting the DB,
moving from one file to another shouldn't be harder as copy/past of
<image> lines.

Anyway, just wanted to share my idea and I really think partitioning the
DB with optionally deferred loading of older partitions could speed up
startup time.

- martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: Digitale Signatur von OpenPGP
URL: <http://mail.kde.org/pipermail/kphotoalbum/attachments/20201014/da7b7e5b/attachment.sig>