Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-75585

Massive performance regression in QML Date object

    XMLWordPrintable

    Details

    • Platform/s:
      Linux/X11
    • Story Points:
      40
    • Sprint:
      Qt6_Foundation_ Sprint 5, Qt6_Foundation_ Sprint 6, Qt6_Foundation_ Sprint 7, Qt6_Foundation_ Sprint 8, Qt6_Foundation_ Sprint 9, Qt6_Foundation_ Sprint 10, Qt6_Foundation_ Sprint 11

      Description

      Commit 2b8b7a162be52f8cd6c2bc39f498a1ddfb59dd68 in qtdeclarative changed QML's DateObject to use QDateTime/QTimeZone in a number of circumstances to fix correctness issues. This is of course a good thing.

      The unfortunate thing is that this seems to have significantly regressed performance. I first noticed this when noting that two QDateTime instances that I change per frame (to represent the current time), which are subsequently bound to in a number of places including by QtQuickControls 1's Calendar, started causing massive (>100%) CPU use under a newer Qt version.

      I wrote a simple qmlbench test (qmlbench change ID I01be0574d6a09abe44336bcbe01ab6360396321f), and the results are as follows:

      with QTimeZone (default implementation on dev)

      • Average: 202.6 frames;; MedianAll=203; StdDev=1.14018, CoV=0.00562772

      undef USE_QTZ_SYSTEM_ZONE

      • Average: 758.2 frames;; MedianAll=757; StdDev=11.0995, CoV=0.0146393

      Some simple digging into the reasons why got me the use of QTimeZone::systemTimeZone() in DaylightSavingTA as being a seriously bad hotspot. I wrote a small change to try address that (qtbase change ID I044a84fc2d3a2dc965f63cd3a3299fc509750bf7), and got the result up quite a bit, but still quite far from the original:

      with QTimeZone cache patch

      • Average: 482.4 frames;; MedianAll=481; StdDev=2.19089, CoV=0.00454165

      I think that the cache patch is required, quite obviously, the current performance just isn't good enough - but I don't think that one patch alone is good enough either. It might be worth looking into whether DateObject can work differently (making use of QDateTime directly), perhaps, or whether there's more savings to be made in QDateTime/QTimeZone.

        Attachments

        1. EXHAUSTIVE.diff
          438 kB
        2. QTBUG-75585.diff
          31 kB
        3. QTimeZone.diff
          14 kB

          Issue Links

          No reviews matched the request. Check your Options in the drop-down menu of this sections header.

            Activity

              People

              Assignee:
              Eddy Edward Welbourne
              Reporter:
              w00t Robin Burchell
              PM Owner:
              Maurice Kalinowski
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: