[zeromq-dev] Important: backward incompatible changes for 0MQ/3.0!

[Martin Sustrik]

On 03/26/2011 12:39 AM, Chuck Remes wrote:

> If anyone would know, it would be you. :)
>
> Since that's the case, then I really don't know what to try next to
> eliminate this slow "leak" that I have in my apps that use 0mq. Until
> I or someone else has a new bright idea, I'll just plan to restart
> the system every 3 days to release back all of the memory they have
> grabbed.

Well, there's an obvious solution, but it's not exactly cheap and fast 
one: Make 0mq allocate less chunks.

For example, brief inspection of the code shows that encoder_t and 
decoder_t both allocate fixed-sized buffer using malloc instead of 
keeping it as a member. Fixing that would decrease amount of allocations 
by 2 per TCP connection.

Then there are STL objects which are often non optimal wrt. number of 
allocated chunks. These can be replaced. Say a length-bound std::string 
can be replaced by a fixed buffer etc.

Btw, note that once a connection is established, the number of 
allocations is highly optimised. In ideal case, 0mq should be able to 
run with zero allocations from that point on. It's the remaining 
out-of-critical-path code that is responsible for almost all the 
allocations.

Martin