It seems replacement for `flowViaChannel(Channel.C...
# coroutines
l
It seems replacement for
flowViaChannel(Channel.CONFLATED) { … }
is
channelFlow<T> { … }.buffer(Channel.CONFLATED)
. Isn't that less efficient as values pass through 2 operators?
e
It is the same. Buffer fuses with channelFlow
l
Was the intention to decouple buffer from the channel flow?
e
Well, decoupling.
API orthogonality to be specific.
So there’s only one operator to configure buffer size or conflation. You can also use conflate() operator as a shortcut.
👌 1
l
Oh, good one. Why isn't it inline?
e
It?
l
conflated()
, which is a shorthand for
buffer(CONFLATED)
, implemented exactly that way.
e
It makes no difference to make it inline.
l
I have been taught function calls are more expensive than an arithmetic operation, and more expensive than no function call. The Android dev docs mentioned this for years (and maybe still do somewhere). It should make a little difference if R8 is not used. I probably worry too much about it though, and debug performance on that order is certainly insignificant.
r
I’ve been taught the same thing. @elizarov are you saying there is actually no difference, or that the difference is so close to 0 that we shouldn’t care?
e
You should not care for this particular case.
l
Now, I'm thinking about that: If you only every use
conflate()
and never call
buffer
directly in your app (including through dependencies), then the apk might finally be a little smaller as
buffer
could be inlined by R8 into
conflate()
, something that might not have been possible or easy to do for R8 if
conflate()
was inlined.
e
Don’t overthink it. All these extra calls happen only during setup of the flow, and do not affect the speed on its subsequent execution which will be transferring far mode data and doing far more calls. If it has some effect, it is of extremely small magnitude to be measurable.