[KPhotoAlbum] Fw: Fwd: [Qt bugreports] Updates for QTBUG-75585: Massive performance regression in QML Date object

[Johannes Zarl-Zierl]

Hi,

Answering to the whole thread in a single message because I'm quite swamped 
and don't have too much time the next few weeks...

So there were several suggestions so far:

(1) Make everything UTZ in the DB, with a separate TZ info
I'm not a huge fan of this solution (even though I also wrote before that we 
may be able to get away with it). This separates the timezone from the image 
date and complicates the handling of datetimes further.
On the plus side, this complements suggestion (2). Yet if we stay with ISO 
date/time representation it actually makes things more complicated.

(2) Store seconds since epoch for performance reasons
I think this is the wrong place to search for performance gains. Robert has 
probably a better understanding of how much time we could save when reading 
the index.xml file, but I assume this to bring very slight gains.

My money is on another suggestion by Robert (some time ago), which is to cache 
the database in sqlite and only do a full read of the index.xml when it was 
changed outside KPhotoAlbum. This would bring us bigger performance gains 
*and* allow us to make use of SQL queries for searching.

(3) Preserve a relatively stable database format
This was and is a core principle of KPhotoAlbum, and a huge reason for me not 
to like (2).

(4) Make sure we think about searching and other UX decisions
ACK

Cheers,
  Johannes



Am Dienstag, 22. September 2020, 09:56:11 CEST schrieb Martin Höller:
> Mail was meant to go to mailinglist...
> 
> --- Begin forwarded message: ---
> 
> Date: Tue, 22 Sep 2020 08:56:49 +0200
> From: Martin Höller <martin at xss.co.at>
> To: Johannes Zarl-Zierl <johannes at zarl-zierl.at>
> Subject: Re: [KPhotoAlbum] Fwd: [Qt bugreports] Updates for QTBUG-75585:
> Massive performance regression in QML Date object
> 
> 
> Hi!
> 
> Just to add some ideas...
> 
> Am 21. Sep. 2020 schrieb Johannes Zarl-Zierl:
> [...]
> 
> > My conclusion to the referenced discussion was that a proper solution
> > would be to add timezone info to the database. A not quite correct
> > solution that could be good enough is probably to convert everything to
> > UTZ.
> > For the current issue, we would need UTZ data only in the database.
> > 
> > So simple solution would be to convert to UTZ and be done with it.
> 
> If times are stored in UTC we could consider not saving it as a string
> representation that would have to be parsed (e.g. "2012-08-16T12:01:09")
> but as (milli)seconds since epoch (e.g. "1345118469"). Parsing a simple
> number is much faster than parsing a date-string.
> 
> We did that in project an thus saved quite a huge amount of parsing time
> on each load (we had several 100 millions of timestamps).
> 
> > I still think that the proper solution to the problem would be to add real
> > timezone support (in the future, more and more cameras will come with EXIF
> > 2.31) and having proper timezone info will allow us to retain local time
> > for display.
> 
> I too think, that's the way to go. But I would save it as a separate,
> additional attribute in XML.
> 
> While we are at it: it would probably be nice to have the opportunity so
> show photo-times as "local time" or as "time taken". You know i looks
> strange, when you see some midnight party photo and KPA says it was taken
> at 15:07:21 because you are in a different timezone when looking at the
> photo.
> 
> > Given that a generic solution in QDateTime seems unlikely, why not
> > implement a wrapper that does the caching? This would not be all that
> > different from our approach with DB::FileName. Just don't call it
> > QuickTime ;-)
> 
> This could be a good approach.
> 
> Another approach might be to use some primitive type like qint64
> internally (which allows for quick comparison) and only convert it to a
> QDateTime when needed (e.g. for formatted output).
> 
> But I really don't know the KPA code, so this might be a lot of work or
> even not suitable for this case.
> 
> Just my 2¢,
> - martin