Hello, Did anyone face any limitation with amount ...

# coroutines

[Łukasz Tokarski]

Hello,
Did anyone face any limitation with amount of Kotlin coroutines launched and suspended simultaneously on the Main (UI-bound) dispatcher. Let's take ~100x flows as an example. Each flow preserves the context and produces the data off the main thread, but the flow is collected in a coroutine launched in Android Activity like:

someRoomMethodReturningFlow01()
  .onEach { println(it) }
  .launchIn(lifecycleScope)

someRoomMethodReturningFlow02()
  .onEach { println(it) }
  .launchIn(lifecycleScope)

...

someRoomMethodReturningFlow100()
  .onEach { println(it) }
  .launchIn(lifecycleScope)

And feedback is more than welcome.

[Łukasz Tokarski]

The Room library seems to take care about proper dispatching for its background work, hence only "observation" takes place on the main.

[uli]

So it is less about the number of flows. But about the accumulated number of emissions per time and the actual processing work load

[Łukasz Tokarski]

yeap, my point (and observation) exactly. Profiling reveals that frequent and parallel emissions from all those streams, lead to some hiccups on the UI thread hence it's time to change the approach. Thanks.

[Zach Klippenstein (he/him) [MOD]]

If you can combine the flows and debounce them off the main thread, that should help

[Łukasz Tokarski]

Yeap, I already apply some kind of sampling for rendering but that needs some improvement. Thx for the hint, Zach