qpid-proton
qpid-proton copied to clipboard
Rotate02
trafficstars
the first commit does fewer buffer defrag/rotates in the case of outgoing deliveries.
the second takes advantage of code of first to promote more fairness in scheduling
third makes many calls to buffer defrag more performant. The first commit ensures that an outgoing delivery is never wrapped, so this optimization always applies. The special case of cj-sender runs > 10x faster, but streaming messages should in aggregate enjoy a performance boost or reduced cpu load.
There are 2 use cases for pn_buffer_t:
- As an intermediate buffer in the output logic chain. In this usage I'm pretty sure that we can stop automatically defragging the buffer and only do it on a specific request. In this world the
pn_buffer_bytesAPI can obviously only return one contiguous segment of the buffer, but there can only be 2 of them so instead of usingpn_buffer_bytesonce to get the whole buffer using it twice in succession will get both segments if the buffer has wrapped. - As a hacky way to manage a grow only buffer that is never in practice defragged anyway - I think all uses of ```pn_buffer_memory`` are like this. We should just introduce a new buffer api for these cases.
Thanks for taking a look.
I will try to rework this as suggested.