Re: g_malloc overhead



Malloc is a system call and has quite bad performance on certain
platforms (windows in particular i think).

Malloc is not a system call. And please don't make performance
assumptions without having benchmark data to back it up. Note that it
is not necessarily that clear what is a "system call" on Windows, as
far as I know.

Something like the gslice allocator could probably improve performance a bit.

At least the g_slice_free() API requires passing the size of the
block, so it is not possible to simply have g_malloc() call
g_slice_alloc(), and g_free() and g_realloc() call g_slice_free().

If you start adding a bookkeeping layer to keep track of the size of
each allocation, you end up with a bunch of code that might well
correspond to what the C library's malloc, or the heap management code
in the kernel32 library (which is code running at user level, not in
the kernel, as far as I know) that it calls, already does anyway.

--tml



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]