qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chuck Rolke <cro...@redhat.com>
Subject Re: Initial results from reducing proton-c coding effort
Date Fri, 02 Mar 2018 22:29:33 GMT
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" <astitcher@redhat.com>
> To: "Qpid Users" <users@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


Mime
View raw message