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

Robert Krawitz rlk at alum.mit.edu
Fri Sep 25 01:55:52 BST 2020


On 9/24/20 6:17 PM, Johannes Zarl-Zierl wrote:
> Hi,
> 
> Am Donnerstag, 24. September 2020, 03:02:30 CEST schrieb Robert Krawitz:
>>> (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.
>>
>> The problen's not with the database loading per se.  The problem is with
>> sorting the list of dates for building the date bar
> 
> Sorry, I did not make myself clear: I was talking about the suggestion to 
> store seconds since epoch in index.xml.

OK. dateTimeFromString accounts for about 7% of the time.  I agree that storing seconds since epoch
in the database file would not make for a big improvement.

> I'm not opposed to fixing the performance issue in the DateBar. Regarding that 
> issue I only question is whether adding additional code "on the outside" of 
> the date+time object is such a good idea. I.e. maintenance-wise, I think the 
> code would stay cleaner if we make a wrapper that encapsulates the 
> performance-tuning. Come to think of it, it might be possible to make the 
> DateBar work with ImageDates instead of QDateTimes - this way we don't even 
> need an additional wrapper class. (Take that last suggestion with a grain of 
> salt - I didn't consult the code yet).

The DateBar does work with ImageDates.  It's the ImageDate class that uses QDateTime.

> One question about this: I assume that we read every datetime at least once 
> and rarely alter a datetime. Why then do the whole dance with the mutable 
> qint64? We could just as well initialize the qint64 on construction and on 
> every modification...

The only thing is that we do need to know whether a QDateTime is invalid; there is specifically
defined behavior in that case.  So we do need that reserved number for that purpose.



More information about the Kphotoalbum mailing list