Re: g_malloc overhead

[BJörn Lindqvist <bjourne gmail com>]

2009/1/21 Liam R E Quin <liam holoweb net>:
> On Mon, 2009-01-19 at 18:43 +0100, BJörn Lindqvist wrote:
>> Actually, a custom allocator could be useful even in the general case.
>> Malloc is a system call and has quite bad performance on certain
>> platforms (windows in particular i think). Something like the gslice
>> allocator could
>> Probably improve performance a bit.
>
> malloc is a library call.

On Linux, it is implemented using mmap() and brk() which are system
calls. The point is that malloc usually translates into one or more
system calls which are expensive. With a custom allocator the system
call part of malloc can be avoided.

> It's not worth changing memory allocators unless you have a good
> solid understanding of how your program uses memory, and have
> done *very* detailed timings.

You are right of course. For GSlice in particular, it was tested
thoroughly when it was merged to glib. See
http://markmail.org/message/ohmuxdfyttuy4ipa. For gtk programs I
believe we have quite good understanding on how applications use
memory.

Another example is Python which also uses a custom memory allocator.
It works very well because Python uses lots of short-lived small
objects.


-- 
mvh Björn