[KPhotoAlbum] Speaking of performance...

[Johannes Zarl-Zierl]

Hi,

Sorry for being short - I'll be fully available again in about a week or so...

W.r.t. the database I agree, but I see this as a mid to long term goal. The most obvious barrier is our current lack of automated testing, which has to do with the missing separation between back end and GUI. We can get to a better place, but it is going to take a bit of effort.

Here are my plans:
https://phabricator.kde.org/T7752

As you can see, changes to the database are also in my list, but I would like to decrease or technical debt to a more sustainable level first.

Cheers,
  Johannes

Am 27. Jänner 2019 16:28:38 MEZ schrieb Robert Krawitz <rlk at alum.mit.edu>:
>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.