Massive performance regression in QML Date object

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.