Repository navigation
Potentially overly slow initial map composition caused by exhaustively setting *all* possible map configuration options #499
Description
android-maps-compose 4.3.0
I see an avoidable performance hit in the code for the initial GoogleMap() subcomposition run: the code essentially configures all possible Map configuration options in an exhaustive manner, rather than only the ones that the API consumer cares about.
This includes CameraPositionState, LocationSource, all 9 properties in MapProperties, GoogleMap padding, and all 10 properties in MapUISettings. At least 22 GoogleMap class function calls upon initial composition, many of which may never actually need to be explicitly set.
Another part of the problem is that the MapView is already being rendered while all these options are set, exhaustively reconfiguring the map while it is being displayed.
All this would not be much of a problem if all the GoogleMap class function calls were guaranteed to execute swiftly. I suspect that this is not the case for all of them, e.g. due to synchronization/locking/blocking and inter-process calls.
Just to be clear: this is a potential architectural and performance problem I see in the code, not something I have actually experienced or tested.
Activity
bubenheimer commentedon Jan 4, 2024
This could potentially be addressed by discontinuing reliance on large preconfigured configuration objects to be passed into the GoogleMap() composable. Instead, configuration lambdas/blocks could be used, e.g.:
These configuration lambdas can be readily executed and observed for changes during composition.
bubenheimer commentedon Jan 5, 2024
In fact, to do this cleanly, it may be necessary to introduce
MapConfigurationStatethat encapsulates all mentioned configuration options, including camera, location source, inside padding. If a user provides a newMapConfigurationStateobject then the GoogleMap & MapView would need to be recreated, unless there is a reliable way to reset the map configuration to defaults.The reason for needing this kind of thing is to keep the Compose API properly declarative. The 2 possible properly declarative approaches I see for this are
MapConfigurationStateor exhaustively setting all options.Alternatively the Map could also be configured from inside the subcomposition/content block via side effects. The inherent constraint of this approach is performance: initial composition of the potentially complex subcomposition needs to be complete before configuration actions can be performed. Arguably, initial map loading should already be happening in parallel during this time. So I think the subcomposition needs to stay reserved for only configuring the map contents, not configuring the map itself.