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" <[email protected]> > To: "Qpid Users" <[email protected]> > 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: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
