| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
Avoid constructing a Calendar only to read the default device timezone. The locale passed to Calendar does not affect the timezone value, so TimeZone.getDefault returns the same value with less work during device context collection. Co-Authored-By: Claude <noreply@anthropic.com>
📲 Install BuildsAndroid
|
Sorry, something went wrong.
Performance metrics 🚀
Baseline results on branch: perf/sdk-overhead-reductionStartup times
App size
Previous results on branch: perf/sdk-overhead-reduction-timezone-defaultStartup times
App size
|
Sorry, something went wrong.
Keep the Calendar-based timezone path for Android 13+ locales that carry a Unicode tz extension. This preserves the existing device timezone behavior while keeping the direct default timezone fast path for normal locales. Co-Authored-By: Claude <noreply@anthropic.com>
There was a problem hiding this comment.
LGTM 👍
Sorry, something went wrong.
|
Cursor review |
Sorry, something went wrong.
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit 2bcedec. Configure here.
Sorry, something went wrong.
There was a problem hiding this comment.
This one is a bit confusing and I'm not sure about the edge cases. Do we have an idea what the performance benefit is here?
Sorry, something went wrong.
|
Benchmark results invoking the util on a newer Android version (API level 34) that does not enter the inner if regarding "tz": ┌─────────────────────────────────────────┬─────────────┬─────────────┬────────┐ │ Metric │ Old/base │ New/head │ Delta │ ├─────────────────────────────────────────┼─────────────┼─────────────┼────────┤ │ Benchmark thread wall time │ 6803.058 ms │ 1624.340 ms │ -76.1% │ ├─────────────────────────────────────────┼─────────────┼─────────────┼────────┤ │ Benchmark thread CPU time │ 6421.307 ms │ 1532.483 ms │ -76.1% │ ├─────────────────────────────────────────┼─────────────┼─────────────┼────────┤ │ CPU per call │ 0.3211 ms │ 0.0766 ms │ -76.1% │ ├─────────────────────────────────────────┼─────────────┼─────────────┼────────┤ │ App process CPU during benchmark window │ 9187.463 ms │ 2716.467 ms │ -70.4% │ ├─────────────────────────────────────────┼─────────────┼─────────────┼────────┤ │ Scheduler slices │ 1037 │ 223 │ -78.5% │ └─────────────────────────────────────────┴─────────────┴─────────────┴────────┘ Results for inner code triggered, e.g. by "en-US-u-tz-usnyc": ┌─────────────────────────────────────────┬───────────────┬───────────────┬───────┐ │ Metric │ Old/base rare │ New/head rare │ Delta │ ├─────────────────────────────────────────┼───────────────┼───────────────┼───────┤ │ Benchmark thread wall time │ 14359.059 ms │ 15315.136 ms │ +6.7% │ ├─────────────────────────────────────────┼───────────────┼───────────────┼───────┤ │ Benchmark thread CPU time │ 13549.090 ms │ 14585.745 ms │ +7.7% │ ├─────────────────────────────────────────┼───────────────┼───────────────┼───────┤ │ CPU per call │ 0.6775 ms │ 0.7293 ms │ +7.7% │ ├─────────────────────────────────────────┼───────────────┼───────────────┼───────┤ │ App process CPU during benchmark window │ 19780.192 ms │ 20366.205 ms │ +3.0% │ └─────────────────────────────────────────┴───────────────┴───────────────┴───────┘ Both benchmarks ran 20k iterations on the util. |
Sorry, something went wrong.
|
Some more info on the "tz": tz is a Unicode locale extension key meaning timezone.
Example:
`en-US-u-tz-usnyc`
Breakdown:
- en-US = English, United States
- u = start of Unicode locale extensions
- tz = timezone extension key
- usnyc = timezone type, here New York
So en-US-u-tz-usnyc roughly means: “English (US), with preferred timezone New York.”
It’s different from the device/system timezone. It’s metadata embedded in the locale tag, mainly for APIs that format calendars/dates according to locale preferences. Android 13+ Calendar.getInstance(locale) can honor this extension, which is why PR #5587 keeps the Calendar path when
locale.getUnicodeLocaleType("tz") != null.
|
Sorry, something went wrong.
Document why Android 13+ locales with Unicode timezone extensions keep using Calendar while normal locales use the default timezone directly for performance. Co-Authored-By: Claude <noreply@anthropic.com>
…o perf/sdk-overhead-reduction-timezone-default # Conflicts: # CHANGELOG.md
| Back | FazBrowse Home | New Git URL |
PR Stack (SDK Overhead Reduction)
📜 Description
Replace the normal Android device timezone path with TimeZone.getDefault() instead of constructing a Calendar just to read its timezone.
One compatibility detail is preserved: Android 13+ Calendar.getInstance(locale) can honor a locale Unicode tz extension (for example en-US-u-tz-usnyc). For those rare locales, the code keeps the Calendar path so the SDK continues reporting the same timezone as before. On Android N through Android 12, and for normal locales without a tz extension, the locale did not affect the timezone value.
💡 Motivation and Context
Part of the SDK Overhead Reduction stack. In the common case, device context collection only needs the process default timezone. TimeZone.getDefault() is available on Android API 21 and Java 8, and avoids constructing a Calendar and reading locale configuration just to retrieve the same timezone.
The previous API 24+ branch used the first Configuration locale, but Android N through Android 12 did not use that locale to select the timezone. Android 13 added tz Unicode extension support to Calendar.getInstance(locale), so this PR preserves that behavior with a narrow fallback while keeping the fast direct-default path for all other cases.
💚 How did you test it?
📝 Checklist
🔮 Next steps
More SDK overhead reduction PRs in this stack.