Summary

The current API for providing composition locals is very allocation heavy and requires several groups. This can be improved in several ways,

The current API will allocated an array to store the providers and a mall object to for each "provides" parameter. It will then create a persistent map of the provided values and then union of the existing map and this map as the persistent scope.

Some composable function just provide one provides which makes these allocation particularly heavey weight. Also, constructing the union persisent map can be expensive.

Proposals

1. Special case single provider

The single provider can be special cased to avoid the creating of the array, the ProvidesValue instance and the persistent map.

This would require new API that takes the composition local definition and the value (as well as a corresponding lint with a quick-fix to migrate code to the new API).

2. Allow building the map directly outside composition.

Instead of building the map in composition, the local map (for large maps) can be constructed as helper or outside composition entirely. This is specifically helpful when the map is conditionally built the current API requires paying the local provider overhead multiple times for shared or conditional providers.

This will require a new API that allows providing a composition local map directly.

3. Faster persistent maps

The persistent map is a general map that handles many cases well but it doesn't handle small changes well (such as adding a single value). We could provide a wrapper around the persistent map that will handles the special cases found in the Compose library better such as a singleton wrapper for cases, such when a single value is provided.

This doesn't require any API changes.