in my experience, custom memory allocators fall into two camps:
1) general memory allocators that effectively replace malloc/realloc/free.
most are written as drop in replacements as mato outlined.
some have a slightly API and so are slightly harder.
2) application level allocator. the classical example are fixed-sized buffers
where free just adds the buffer to a freelist and when you run out,
you malloc a boatload and add them to teh free list. these normally
outperform general allocators because they embody use-specific
knowledge.
type 2) allocators need support within libzmq -- it can't be done as a dropin
replacement.
andrew
On Mar 25, 2011, at 4:05 AM, gonzalo diethelm wrote:
>> So, I'd like to ask again: Gonzalo, Douglas, and others here asking for a
>> custom memory allocator: Can you not use the above solution? If so, why
>> not?
>
> Yes, definitely that is a good and cheap way of improving memory allocation.
> But from previous experience, having a custom allocator is also great for
> weird / corner cases (like using shared memory), although you are correct, it
> is a very invasive change.
>
> --
> Gonzalo Diethelm
>
> _______________________________________________
> zeromq-dev mailing list
> [email protected]
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
------------------
Andrew Hume (best -> Telework) +1 623-551-2845
[email protected] (Work) +1 973-236-2014
AT&T Labs - Research; member of USENIX and LOPSA
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
