New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update threetenbp to v1.3.4 and use ZoneRulesInitializer for on-demand initialization #53

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
2 participants
@mmallozzi
Contributor

mmallozzi commented May 17, 2017

With this change, almost nothing will need to happen at application startup - the initializer (along with the application context) will be registered, but any other library code execution will be deferred until ZoneRulesProvider is initialized when ThreeTenBP first needs to make use of time zone data later on in execution. Most notably, this prevents ServiceLoader from being used to try to load time zone data, as that was a big performance hit within ThreeTenBP before on Android devices.

Update threetenbp to v1.3.4 and use ZoneRulesInitializer for on-deman…
…d initialization

With this change, almost nothing will need to happen at application startup - the initializer (along
with the application context) will be registered, but any other library code execution will be deferred
until ZoneRulesProvider is initialized when ThreeTenBP first needs to make use of time zone data later
on in execution. Most notably, this prevents ServiceLoader from being used to try to load time zone
data, as that was a big performance hit within ThreeTenBP before on Android devices.
@JakeWharton

This comment has been minimized.

Owner

JakeWharton commented May 17, 2017

Did you see #52?

@mmallozzi

This comment has been minimized.

Contributor

mmallozzi commented May 17, 2017

Ah nope you beat me to it! This approach is what I had in mind when I made those ThreeTenBP changes, since it would allow initialization to be deferred until necessary, rather than paying the initialization cost on every app startup. In larger apps where features requiring time zone data won't always be executed, this makes a big difference. Using the DO_NOTHING version helps to bypass ServiceLoader which is certainly a big performance killer, but using a custom initializer would allow you to make the entire thing lazy. It may actually be a good idea to provide two different initialization options, like init() and initLazy(), so that app developers can decide whether they want to slow down startup in exchange for good response time later, or do almost nothing at startup but risk some jank later when the data is needed.

@mmallozzi

This comment has been minimized.

Contributor

mmallozzi commented Jul 11, 2017

Thoughts here? In my own code I've been using lazythreetenbp which incorporates similar changes to this PR and has been running stably for a couple months, but which also addresses #23 for lazy loading.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment