raboof commented on PR #2409: URL: https://github.com/apache/pekko/pull/2409#issuecomment-3468221534
> > This is a trade-off between latency and compression performance: in a naive implementation, if we for instance 'keep asking elements to buffer' on the boundary of 2 elements of a gRPC stream, it would delay sending+processing the first element while waiting for the next element to show up - which could take a long time on 'event streams', for example. It's possible to avoid this problem: we could 'keep asking for elements to buffer' only when there's currently no demand from downstream, but compress and send 'everything we have' as soon as demand is signaled. That might be significantly more complex, though. > > Good point, I did miss that. I am currently doing an initial implementation that follows the logic I described, but it can be improved on later to bypass the accumulation of data if downstream is demanding data right now. I assume that you would use `hasBeenPulled(port)` to figure out if there is downstream demand? From https://pekko.apache.org/docs/pekko/current/stream/stream-customize.html it looks like `hasBeenPulled` is for input ports, and `isAvailable` would be the thing to check. You'd also need to make sure that your flow signals demand even when downstream doesn't (until the buffer is 'full'). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
