I've checked in a few easy tweaks that should help some of the worst offenders in your list. I don't know close it will get you to your goal, but it would be helpful if you could rerun your test against the latest code on trunk.
--Rafael On Fri, May 9, 2014 at 11:41 AM, dcjohns41 <david.johns...@honeywell.com>wrote: > Thanks for the various suggestions on capturing the memory allocation. We > started the process and have found several areas that seem to be large RAM > users. Proton-C_MemoryAllocation.xlsx > < > http://qpid.2158936.n2.nabble.com/file/n7607980/Proton-C_MemoryAllocation.xlsx > > > > The attached file is a list of the main startup allocation. In the > rightmost column, we have highlighted any allocation that is larger in size > in red. As you can see there are several 16KByte chunks of RAM allocated > (object.c /pni_map_allocate) as well as multiple 960 byte chunks(over 24 > occurrences for approx. 24Kbytes)(pn_data.c). Also the pn_buffer and > pn_dispatcher functions each allocate 4Kbytes. This exceeded 75Kbytes > prior > to our system being able to attempt communication setup. > > So this drives a few questions as to being able to minimize these > allocations. The multiple 960 byte allocations and the 32Kbyte allocations > seem to be the big hitters. > > Any hints from the mailing list on reducing these structures? > > Dave > > > > -- > View this message in context: > http://qpid.2158936.n2.nabble.com/Minimizing-the-Proton-Engine-Messenger-RAM-Footprint-for-embedded-devices-tp7607409p7607980.html > Sent from the Apache Qpid Proton mailing list archive at Nabble.com. >
