Add MessageToBufferedByteEncoder for better performance#5510
Add MessageToBufferedByteEncoder for better performance#5510normanmaurer wants to merge 1 commit into4.1from
Conversation
Motivation: MessageToMessageEncoder always allocate a new buffer per encode call and pass it through the pipeline via a write call. This can have negative performance impact if the users does a lot of write calls before doing a flush as this may produce a lot of small buffers that needs to get allocated and also written to the underlying transport. For this situations it can be a lot better to just allocate one buffer, encoder everything into this buffer and only write it the the transport once a flush happens. Modifications: Add a new MessageToBufferedByteEncoder which should be used if more writes then flush operations are expected. Result: Better performance.
|
@Scottmitch @buchgr @trustin PTAL |
|
This looks good to me, want to merge? |
|
Also we might want to add option to limit max cumulation size to avoid too big buffers being allocated? In my message cumulator there's a limit of 16kb, but it was working another way(encode every message to it's own buffer and then merge to new buffer...so the limit was to avoid too much memcpy with big packets). |
| if (readable < 0) { | ||
| throw new IllegalStateException("readableBytes are less then before calling encode(...)"); | ||
| } | ||
| outboundBuffer.incrementPendingOutboundBytes(readable); |
There was a problem hiding this comment.
This crosses API boundaries and exposes an internal API which I would prefer to avoid. I don't necessarily have a better idea, but we may have the same issue with SslHandler or other handlers which aggregate writes (e.g. ProxyHandler).
There was a problem hiding this comment.
@Scottmitch in we use PendingWriteQueue which takes care of this for us. Maybe I could just use it here as well. Let me give it a shoot.
|
Let me just close this for now. |
Motivation:
MessageToMessageEncoder always allocate a new buffer per encode call and pass it through the pipeline via a write call. This can have negative performance impact if the users does a lot of write calls before doing a flush as this may produce a lot of small buffers that needs to get allocated and also written to the underlying transport. For this situations it can be a lot better to just allocate one buffer, encoder everything into this buffer and only write it the the transport once a flush happens.
Modifications:
Add a new MessageToBufferedByteEncoder which should be used if more writes then flush operations are expected.
Result:
Better performance.