New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sending to full Channel<Unit>(CONFLATED) is ~10x slower than sending to full Channel<Unit>(1) #4048
Comments
FTR, the benchmark:
The root cause is clear (in fact, it is properly highlighted in the original report), but the fix is not -- in order to proceed with that, we should repeat what we did in old channels -- provide a dedicated "conflated; buffer = 1" implementation of the channel, which is an additional maintenance burden and a contribution to the library size. Could you please elaborate on how frequent/often the use-case "conflated channel of Unit to notify the other party"? How performance-sensitive is it? |
Channel<Unit>(CONFLATED)
is a pattern frequently used for signalling in coroutine-based environment. In cases when the channel already contains an element (e.g. receiver is delayed), callingsend
causesChannel
to drop the previous element and replace it with the old one. This behavior is expected and matches documentation ofChannel.CONFLATED
, but is significantly slower thanChannel<Unit>(1)
, which preserves the original object instead. In cases when the channel can only send/receive the same object (Unit
===Unit
), the defaultCONFLATED
behavior could be optimized to be more efficient.Running the benchmarks on Pixel 5:
Produces the following results:
From the results above, sending to empty channel is roughly the same for both
Channel(CONFLATED)
andChannel(1)
, but sending to already full channel is ~10x slower.The text was updated successfully, but these errors were encountered: