Coalesce all merged run effects into a single task group. #3615
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I noticed that if one were to
.merge
many.run
effects, that it would create as many task groups as there were effects in the list of effects (minus 1). I suspected this may use more memory than needed, so I tried coalescing all run effects into a single task group to save on memory usage.I ran something like the following code on the simulator both with and without my change to test my hypothesis, in an arbitrary reducer:
I'm using a lot of tasks here to make the memory usage differences much more obvious in the memory used metrics in xcode's debugging navigator.
When putting that code into a screen in the swiftui case studies app, without my change the app used approximately 43 MB of memory while the tasks were active, and with my change it used 41.5 or so MB of memory while the tasks were active. This shows that there could be some memory savings gained here especially if some effects in a large group of merged effects are long-lived or if one of them never ends.
Two things I can think of that might be concerns here are the order that effects are initiated is different here; since run effects are coalesced together, if theyre mixed with publisher effects they won't initially trigger in the same order as before this change. The second thing is wrapping the
some Sequence<Self>
in an unchecked sendable to pass it along to the task group may not be safe. We could create an interim array instead if doing so isn't a concern, but for pathological cases like my test case that may take extra time. If there's little or no concern of assuming that any sequence used here could be safely considered sendable though then it may work fine.If there's any concerns with this change I can address let me know!