<@U2E974ELT> Current implementation of channels al...

# coroutines

[gildor]

@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

[elizarov]

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.

[elizarov]

Note, that optimizing channels is a separate activity from enabling many use-cases without channels at all. Light-weight Rx-style cold streams should enable many things that channels are currently used for without any overheads of the channels (full concurrency support is the main overhead in channels, not memory allocation itself)

[gildor]

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

[gildor]

but never saw discussion about memory and allocations overhead

[gildor]

just to show my use case, I would like to subscribe from one thread (just a launch with dispatcher) to events on another thread

[elizarov]

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).

[gildor]

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

[elizarov]

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

[gildor]

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

[elizarov]

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.

[gildor]

I see, looks promising

[gildor]

in general channels (or channels-like api) look really clear and easy to use for UI and together with ConflatedBraodcastChannel provides pretty simple API to convert callbacks to stream of events.
Looking forward to cold streams

[elizarov]

I think that ConflatedBroadcastChannel, in particular, can be optimized for allocation-free work. Needs some thought.

[gildor]

interesting

[elizarov]

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)

[elizarov]

Recorded your concerns here: https://github.com/Kotlin/kotlinx.coroutines/issues/395

[gildor]

Thanks!
Would like to test any prototype of this solution