[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