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

[Robert Krawitz]

Here's the answer I got.


-------- Forwarded Message --------
Subject: [Qt bugreports] Updates for QTBUG-75585: Massive performance regression in QML Date object
Resent-Date: Mon, 21 Sep 2020 06:26:44 -0400 (EDT)
Resent-From: rlk at alum.mit.edu
Date: Mon, 21 Sep 2020 10:26:00 +0000 (UTC)
From: Edward Welbourne (via JIRA) <jira-noreply at qt-project.org>
To: rlk at alum.mit.edu

Qt / QTBUG-75585 [Closed]
Massive performance regression in QML Date object

==============================

Here's what changed in this issue in the last few minutes.

There is 1 comment.

View or comment on issue using this link
https://bugreports.qt.io/browse/QTBUG-75585

==============================
 1 comment
------------------------------

Edward Welbourne on 21 Sep '20 06:10
{{QDateTime}}'s comparison operators use a cheap comparison when both date-times are in local time
(-which may actually be flawed, when one is in each half of a time-zone fall-back, e.g. the end of
DST-).  Otherwise, it falls back on the relatively expensive comparison by conversion to UTC epoch time.
(The same optimisation would make no difference for UTC and fixed-offset-from-UTC date-times.
It could, however, be applied to time-zone-based date-times.)
Local-time date-times don't (always) record their offset from UTC, so are obliged to work it out
each time we compute their milliseconds from the UTC epoch; this is distinctly sub-optimal, but hard
to fix without a significant rewrite.

If it's possible to change your application to use UTC date-times, instead of local date-times, that
should significantly speed up your sorting.  For example, change
{code:c++}
      QDateTime date;
      date.setSecsSinceEpoch(start);
{code} to {code:c++}
      QDateTime date = QDateTime::fromSecsSinceEpoch(start, Qt::UTC);
{code}

(Edit: a local time does, however, remember whether it's in DST or standard time, so two times in a
fall-back described the same way are still distinguished, thankfully.)
was:
  {{QDateTime}}'s comparison operators use a cheap comparison when both date-times are in local time
(which may actually be flawed, when one is in each half of a time-zone fall-back, e.g. the end of
DST)  Otherwise, it falls back on the relatively expensive comparison by conversion to UTC epoch time.
  (The same optimisation would make no difference for UTC and fixed-offset-from-UTC date-times.
  It could, however, be applied to time-zone-based date-times.)
  Local-time date-times don't (always) record their offset from UTC, so are obliged to work it out
each time we compute their milliseconds from the UTC epoch; this is distinctly sub-optimal, but hard
to fix without a significant rewrite.
    If it's possible to change your application to use UTC date-times, instead of local date-times,
that should significantly speed up your sorting.  For example, change
  {code:c++}
        QDateTime date;
        date.setSecsSinceEpoch(start);
  {code} to {code:c++}
        QDateTime date = QDateTime::fromSecsSinceEpoch(start, Qt::UTC);
  {code}


==============================
 This message was sent by Atlassian Jira (v8.5.4#805004-sha1:0444eab)