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
