-
Bug
-
Resolution: Unresolved
-
P2: Important
-
None
-
6.3.0
-
None
-
-
21
-
Foundation PM Prioritized
There seems to be a severe performance regression in how QDateTime handles dates with very low years (probably all years below epoch). This manifested in our application with severe stuttering.
This code reproduces the problem quickly:
QElapsedTimer timer; timer.start(); for (qint64 i = 0; i < 1E7; i++) QDateTime someday(QDate(1, 1, 1), QTime(0, 0)); qDebug() << "Elapsed:" << timer.elapsed();
This code takes a huge amount of time, I didn't even reach the end. If you replace the year with a value > 1970, then the time to complete is reasonable.
I can reproduce this in MacOS and Windows. I cannot reproduce in Linux.
Qt 5.15 does not seem to be affected.
| For Gerrit Dashboard: QTBUG-104012 | ||||||
|---|---|---|---|---|---|---|
| # | Subject | Branch | Project | Status | CR | V |
| 414428,3 | Make two QDT benchmarks data-driven and add more rows | dev | qt/qtbase | Status: MERGED | +2 | 0 |
| 416319,2 | Make two QDT benchmarks data-driven and add more rows | 6.4 | qt/qtbase | Status: MERGED | +2 | 0 |
| 416320,3 | Make two QDT benchmarks data-driven and add more rows | 6.3 | qt/qtbase | Status: MERGED | +2 | 0 |
| 416321,3 | Make two QDT benchmarks data-driven and add more rows | tqtc/lts-6.2 | qt/tqtc-qtbase | Status: MERGED | +2 | 0 |
| 416322,4 | Make two QDT benchmarks data-driven and add more rows | tqtc/lts-5.15 | qt/tqtc-qtbase | Status: MERGED | +2 | 0 |
| 492687,3 | Refine minor details in Darwin time-zone backend | dev | qt/qtbase | Status: MERGED | +2 | 0 |
| 492688,5 | Refine QTimeZonePrivate::dataForLocalTime() | dev | qt/qtbase | Status: MERGED | +2 | 0 |