These are good improvements. Proton-j is doing most of this already.
PROTON-1780 is perhaps more complicated than it seems however. One of
the things proton-j always did is try to encode the smallest list/map
types it could, and a lot of the time it was notably slower because of
the time spent doing that. One of the things done in tweaking it of
late was to ensure it doesnt waste nearly so much time trying to
figure out and handle that in various common cases such as encoding
many of the frames, sections, some dispositions etc.

Robbie

On 2 March 2018 at 16:06, Andrew Stitcher <astitc...@redhat.com> wrote:
> I've now checked in my work to reduce some of the known coding overhead
> in proton-c.
>
> There were 3 parts to this:
>
> 1. Stop generating nulls at the end of described lists - if they are
> not there the decoder must assume they are null - defualt values.
>
> 2. Generate nulls instead of default values everywhere possible - I may
> have missed a few places, but have hit the commonly used frames -
> transfers, flows and dispositions.
>
> 3. Generate LIST0 types instead of LIST8/LIST32 for zero length lists.
> This is an optimisation then seems specifically to help frame
> generation in a few places.
>
> There are some known improvements that still need to happen to make
> coding as efficient as I know about - these are in PROTON-1779 [1] and
> PROTON-1780 [2]. These are omitting HEADER and PROPERTIES sections from
> message payloads when they are all default; and generating LIST8/MAP8
> types instead of LIST32/MAP32 where we can.
>
> I performed 2 simple benchmarks agains 0.21 (which itself has some
> simple improvements too):
>
> 1. The size of a minimum message payload:
>
> Using this simple python:
>
> from proton import *
> m = Message()
> d = m.encode()
> print len(d)
>
> The reduction is from 43 bytes in 0.21 to 8 bytes in 0.22.
>
> If I'd measured the transfer frame I might have got a bigger reduction
> as the transfer frame itself should be a bit smaller too. This leads
> to:
>
> 2. Bytes transferred using simple_send
> [My measurement methodology is a little bit suspect, but should only be
> 10-30 bytes out for each measurement]
>
> In this case I just ran simple_send.cpp with default settings (100
> messages of around 20 bytes payload) against broker.cpp and recorded
> the raw bytes from both ends using PN_TRACE_RAW=1.
>
> In this case the reduction is from ~12100 for 0.21 to ~9000 for 0.22.
> This is ~31 byte reduction per message overall including all changes -
> I think this test had flows/dispositions every 10 messages.
>
> Naturally, this reduction is going to be most noticeable when using
> smaller message sizes.
>
> Andrew
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Reply via email to