Composed 2.0.0-beta.8
- Tags:
- open-source
My overall goal here was to measure and then improve all common API usage. This boils down to:
The test results are as follows, comparing to ea6375881e2636b253ab1138ab23bbe99cdf4c1a (which we use now). As you can see, everything is faster, with testPerformanceOfAddingManyChildrenWithManyNodesInTree
being much faster now.
| Test | ea6375881e2636b253ab1138ab23bbe99cdf4c1a | Now |
|------|-------|-----|
| testPerformanceOfFindingLastSectionOffset
| 0.0000322 s | 0.00000792 s |
| testPerformanceOfFindingLastSectionProviderOffset
| 0.00105 s | 0.000683 s |
| testPerformanceOfFindingSectionProviderBeforeLastOffset
| 0.0000326 s | 0.0000118 s |
| testPerformanceOfFindingSectionBeforeLastOffset
| 0.00107 s | 0.000712 s |
| testPerformanceOfAddingManyChildrenWithManyNodesInTree
| 21.3 s | 0.0668 s |
| testPerformanceOfAddingManyChildrenToSingleComposedSectionProvider
| 0.000196 s | 0.000115 s |
Note that this is testing some specific hot paths (namely appending) and the non-hot-paths.
Also note that these are extreme tests; we end up with over 19,500 total sections. The most I've seen in the app is more like 700-800.
There are a few different things contributing to this speed up:
AggregateSectionProvider
.
ComposedSectionProvider
now sends itself as the provider
for delegate calls
ComposedSectionProvider.providers
is no longer computed, so lookups are much faster.SectionProviderMapping
.
ComposedSectionProvider
directly now for this.FlatSection
This PR has a few changes rolled in to one. This is being used with the Xcode 16.1 changes in the main app.
@MainActor
is a few places. This is going to supersede https://github.com/opennetltd/Composed/pull/4.CellUpdateMethod
has been added, which allows us to perform a reconfigure rather than a reload, improving the performance when the layout has not changed.
OneTimeCodeInputSection
.This is a relatively small change to remove the elements provider cache from CollectionCoordinator
.
This will have some performance impact, but I am opening this as a draft because if we find a method of recreating the header bug I would like to test this change.
To actually incorporate this change we should update all the SingleUICollectionViewSection.section(with:)
implementations to cache what is returned, otherwise the impact may be too large. Since most sections don't actually care about the trait collection we could update SingleUICollectionViewSection
to require a property (which we then implement using a lazy private(set) var
) rather than a function and add a separate protocol for varying by trait collection.
We stand to benefit from caching the values returned by SingleUICollectionViewSection
implementations even without these changes, but for now I am focussed on recreating the header bug.
This PR is primarily focussed on improving support for compositional layouts, however it also provides some improvements for flow layouts too.
UICollectionViewCompositionalLayout
to ease debugging section providers that include children that have not yet adopted CompositionalLayoutHandler
debugLog
has been updated to use an auto closure for the message