Repository navigation
Unnecessary map initialization performance penalty caused by delaying composing GoogleMap() subcomposition until after GoogleMap object is available #501
Description
android-maps-compose 4.3.0
From code inspection I've noticed that there is an undue performance penalty caused by delaying the GoogleMap() subcomposition until after the GoogleMap object has been made available via suspending MapView.awaitMap().
While the GoogleMap object is required during the "apply changes" phase of the subcomposition, it should not be required to perform the initial composition of the subcomposition, prior to "apply changes".
Initial composition phase of subcomposition and MapView.awaitMap() should and can be performed in parallel.
Reacted by Seb Jachec
Activity
bubenheimer commentedon Jan 5, 2024
Just as an aside thought, not directly linked to this issue: the initial composition phase of the
GoogleMap()subcomposition theoretically would not need to be performed on the main thread, which would free the main thread for other concurrent initialization tasks. This may be too risky to attempt for now.bubenheimer commentedon Jan 7, 2024
Another element to consider here: MapsInitializer may need to be a part of an app's map initialization pipeline: the
GoogleMap()subcomposition composition phase should not be delayed until after MapsInitializer is done; it can run in parallel.Delay GoogleMap object access until composition apply phase (see goog…
fix: Use recomposed map listener callbacks rather than only the initi…
chore(release): 4.3.3 [skip ci]
bubenheimer commentedon Jan 31, 2024
@wangela Just FYI: the 4.3.3 release says that it fixes this issue, but that is not the case. I think this mixup happened because I mentioned this issue in one of the commits for 4.3.3 ("see #501", I was not aware that this has "fixes" semantics, maybe some problem with release automation, or maybe I shouldn't do this in commit messages?).
wangela commentedon Feb 27, 2024
@bubenheimer Where are you seeing that the release says it fixes this issue 501? I only see it mentioning that it fixes issue 466 which was tagged intentionally on your PR number 478.
bubenheimer commentedon Feb 27, 2024
@wangela That link says it "closes" #501
wangela commentedon Feb 27, 2024
Strange, may be human error. I've deleted that mention from the release notes.
bubenheimer commentedon May 14, 2024
I've added two related issues on the Google issue tracker:
https://issuetracker.google.com/issues/340494390
https://issuetracker.google.com/issues/340476594