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 _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
