https://kotlinlang.org logo
Title
g

gildor

06/11/2018, 8:48 AM
@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
1
e

elizarov

06/11/2018, 8:50 AM
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.
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)
g

gildor

06/11/2018, 8:52 AM
Yes, I’m aware about atomics and other concurrency-related overhead
but never saw discussion about memory and allocations overhead
just to show my use case, I would like to subscribe from one thread (just a
launch
with dispatcher) to events on another thread
e

elizarov

06/11/2018, 8:55 AM
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).
g

gildor

06/11/2018, 8:56 AM
I thought that cold streams are not about threading but more about data processing
e

elizarov

06/11/2018, 8:56 AM
Alternative is to use locking (that is what Go does), but it limits scalability.
g

gildor

06/11/2018, 8:58 AM
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
e

elizarov

06/11/2018, 8:58 AM
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.
g

gildor

06/11/2018, 8:58 AM
I see, looks promising
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
e

elizarov

06/11/2018, 9:03 AM
I think that
ConflatedBroadcastChannel
, in particular, can be optimized for allocation-free work. Needs some thought.
👍 2
g

gildor

06/11/2018, 9:03 AM
interesting
e

elizarov

06/11/2018, 9:05 AM
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)
g

gildor

06/11/2018, 9:09 AM
Thanks! Would like to test any prototype of this solution