From f4e83fccb4ecbf01ba9b72b02a1041e93e7c92b3 Mon Sep 17 00:00:00 2001 From: Volker Krause Date: Fri, 5 Jan 2024 17:10:41 +0100 Subject: [PATCH] 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.7 6.6 6.5 Change-Id: I5f175137b8b71816347a8debb492214427a51104 Reviewed-by: Edward Welbourne --- src/corelib/time/qtimezone.cpp | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/src/corelib/time/qtimezone.cpp b/src/corelib/time/qtimezone.cpp index e4d17596d8e..5f5d104baf1 100644 --- a/src/corelib/time/qtimezone.cpp +++ b/src/corelib/time/qtimezone.cpp @@ -456,8 +456,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