@elizarov Current implementation of channels allocates a few object on each item in a channel. For example this is what ConflatedBraodcastChannel allocates for each `send(value)`:

CancallableContunuationImpl

,

AbstractChannel.ReceiveHasNext

,

ChildContinuation

,

ConflatedBroadcastChannel.State

and lambda of

ReceiveChannel.consume

. Isn’t this too much? It’s fine for many cases. But if you want to work with UI drawing events (60 per second in case of Android) it looks like significant overhead

Yes. Optimizing channels was not a priority thus far (even though it is already quite competitive compared to Akka and Go channels), but we plan to dedicate some effort towards channel optimizations this summer.

Yes, I’m aware about atomics and other concurrency-related overhead

It is there. It is somewhat related to concurrency, though. You can implement all the channel concurrency contracts w/o memory allocation overhead, but it is harder from algorithmic standpoint. It is usually easier to implement concurrent data structures by allocating fresh objects for operations (you don’t need to worry about ABA problems).

I thought that cold streams are not about threading but more about data processing

Alternative is to use locking (that is what Go does), but it limits scalability.

maybe we need some primitive in coroutines to enable such use cases, for UI development you usually want to connect UI with some IO and because of asynchronous nature of UI you want to do that using some listener/channel of events

Cold streams are about data processing, but with cold-streams we also gain unique performance advantages over channels. For example, when you need to send a cold stream to another thread you know that you have only a single producer and a single consumer and it can be implemented way more efficiently than MPMC channels that we currently provide.

I see, looks promising

I think that

ConflatedBroadcastChannel

, in particular, can be optimized for allocation-free work. Needs some thought.

interesting

It is non-trivial to avoid ABA problem there (without allocation), but some seqlock-like approach could be used (locking it on update of the value does not pose a scalability problem there)

Thanks! Would like to test any prototype of this solution