Optimize QTimeZone construction on Android
isTimeZoneIdAvailable() is significantly slower than just trying to initialize the timezone and see if that worked. Even in the x86 emulator the difference for this is from 2+ms to no longer measurable here, on less powerful ARM devices it's even more extreme. This matters in particular for code creating many QTimeZone instances, e.g. for calendaring. Pick-to: 6.6 6.5 Change-Id: I5f175137b8b71816347a8debb492214427a51104 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> (cherry picked from commit f4e83fccb4ecbf01ba9b72b02a1041e93e7c92b3) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This commit is contained in:
parent
5010ab2275
commit
8762c3bbde
@ -471,8 +471,15 @@ QTimeZone::QTimeZone(const QByteArray &ianaId)
|
||||
if (!d->isValid()) {
|
||||
if (ianaId.isEmpty())
|
||||
d = newBackendTimeZone();
|
||||
#ifdef Q_OS_ANDROID
|
||||
// on Android the isTimeZoneIdAvailable() implementation is vastly more
|
||||
// expensive than just trying to create a timezone
|
||||
else
|
||||
d = newBackendTimeZone(ianaId);
|
||||
#else
|
||||
else if (global_tz->backend->isTimeZoneIdAvailable(ianaId))
|
||||
d = newBackendTimeZone(ianaId);
|
||||
#endif
|
||||
// else: No such ID, avoid creating a TZ cache entry for it.
|
||||
}
|
||||
// Can also handle UTC with arbitrary (valid) offset, but only do so as
|
||||
|
Loading…
x
Reference in New Issue
Block a user