Re: Fw: Fwd: [Qt bugreports] Updates for QTBUG-75585: Massive performance regression in QML Date object
Robert Krawitz <rlk-FrUbXkNCsVf2fBVCVOL8/[email protected]> Thu, 24 Sep 2020 20:55:52 -0400
| Newsgroups | gmane.comp.kde.kimdaba |
|---|---|
| Message-ID | <[email protected]> |
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.