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

[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
-------------- 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/20200922/5dded757/attachment.sig>