diff options
author | Robin Burchell <robin.burchell@crimson.no> | 2019-05-03 20:02:10 +0200 |
---|---|---|
committer | Edward Welbourne <edward.welbourne@qt.io> | 2020-03-20 16:58:09 +0200 |
commit | 2af04860f6536bbbf82ee21d6aa95ca33a60fbf5 (patch) | |
tree | b5388ea57e36cccc6a2f50acd5013681bd6b019f /src/corelib/Qt5CoreConfigExtras.cmake.in | |
parent | d535dfea1f2d801268396f328c5c99968ff164ec (diff) |
qtimezoneprivate_tz: Apply a cache over the top of timezone data
Constantly re-reading the timezone information only to be told the exact
same thing is wildly expensive, which can hurt in operations that cause
a lot of QTimeZone creation, for example, V4's DateObject - which
creates them a lot (in DaylightSavingTA).
This performance problem was identified when I noticed that a
QDateTime binding updated once per frame was causing >100% CPU usage
(on a desktop!) thanks to a QtQuickControls 1 Calendar (which has a
number of bindings to the date's properties like getMonth() and so
on).
The newly added tst_QTimeZone::systemTimeZone benchmark gets a ~90%
decrease in instruction count:
--- before
+++ after
PASS : tst_QTimeZone::systemTimeZone()
RESULT : tst_QTimeZone::systemTimeZone():
- 0.024 msecs per iteration (total: 51, iterations: 2048)
+ 0.0036 msecs per iteration (total: 59, iterations: 16384)
Also impacted (over in QDateTime) is
tst_QDateTime::setMSecsSinceEpochTz(). The results here are - on the
surface - less impressive (~0.17% drop), however, it isn't even
creating QTimeZone on a hot path to begin with, so a large drop would
have been a surprise.
Added several further benchmarks to cover non-system zones and
traverse transitions.
Done-With: Edward Welbourne <edward.welbourne@qt.io>
Task-number: QTBUG-75585
Change-Id: I044a84fc2d3a2dc965f63cd3a3299fc509750bf7
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Diffstat (limited to 'src/corelib/Qt5CoreConfigExtras.cmake.in')
0 files changed, 0 insertions, 0 deletions