Initial results from reducing proton-c coding effort

[Andrew Stitcher <as...@redhat.com>]

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-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: Initial results from reducing proton-c coding effort

[Robbie Gemmell <ro...@gmail.com>]

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 <as...@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-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>

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

Re: Initial results from reducing proton-c coding effort

[Chuck Rolke <cr...@redhat.com>]

Good work. These changes will be a great candidate to test with
qpid-interop to make sure that it still works with the other 
implementations. And if not then why not.

----- Original Message -----
> From: "Andrew Stitcher" <as...@redhat.com>
> To: "Qpid Users" <us...@qpid.apache.org>
> Sent: Friday, March 2, 2018 11:06:18 AM
> Subject: Initial results from reducing proton-c coding effort
> 
> 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-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
> 
> 

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