Re: Speaking of performance...

Bruno Pagani <[email protected]> Sun, 27 Jan 2019 19:56:51 +0100

Newsgroups	gmane.comp.kde.kimdaba
Message-ID	<[email protected]>

Le 27/01/2019 à 16:28, Robert Krawitz a écrit :
> We really do need to attack the startup performance somehow, for
> people (like myself) with big collections.  I currently have a little
> over 300,000 shots in my collection, and depending upon how well we do
> in the postseason that could increase by another 10% over the next few
> months.  It takes about 13 seconds for kpa to start up, largely due to
> the XML parsing.  Since the XML file is "only" 57 MB, it's clearly not
> I/O-limited.
>
> I understand (and agree with) the desire for a readable and editable
> file format.  I've fixed things up myself on occasion.  But I don't
> want to pay that kind of startup price every time.
>
> What I'm thinking in terms of is to save the file in two formats, a
> fast format (which could be an SQL database, a binary serialization,
> or such) and the XML format.  The fast format would have an embedded
> timestamp; if the XML file were newer, it would be used instead, or
> the user would be prompted to choose which.
>
> Autosave would save only the fast format (possibly only a delta, but
> that would likely be quite difficult).  Full save would save both
> formats; if we were really clever, we might be able to parallelize the
> two operations.

I don’t have a lot of knowledge in that domain, but this might be of
interest:

https://github.com/hughsie/libxmlb/

Regards,
Bruno

_______________________________________________
KPhotoAlbum mailing list
[email protected]
https://mail.kdab.com/mailman/listinfo/kphotoalbum

signature.asc (application/pgp-signature, 488 B)