Re: landing g_slice_*() in glib
- From: Tim Janik <timj gtk org>
- To: Alexander Larsson <alexl redhat com>
- Cc: Gtk+ Developers <gtk-devel-list gnome org>
- Subject: Re: landing g_slice_*() in glib
- Date: Fri, 2 Dec 2005 09:48:39 +0100 (CET)
On Fri, 2 Dec 2005, Alexander Larsson wrote:
On Fri, 2005-12-02 at 02:55 +0100, Tim Janik wrote:
g_malloc/g_free:
Starting 1 threads allocating random blocks <= 1024 bytes with seed=123456789 using slab allocator + magazine cache
real 0m16.784s
internal slab allocator:
Starting 1 threads allocating random blocks <= 1024 bytes with seed=123456789 using slab allocator
real 0m26.040s
g_slice_*() (slab allocator + magazine cache):
Starting 1 threads allocating random blocks <= 1024 bytes with seed=123456789 using system malloc
real 1m40.123s
This part obviously has the headers in the wrong order. g_malloc is the
one that takes 1m40s.
thanks, you're right.
Also, are you making GType use g_slice for allocation of objects instead
of memchunks (if n_preallocs is set)?
memchunks in cvs are already using g_slice_*:
gpointer
g_mem_chunk_alloc (GMemChunk *mem_chunk)
{
g_return_val_if_fail (mem_chunk != NULL, NULL);
return g_slice_alloc (mem_chunk->alloc_size);
}
and gtype.c also uses g_slice_*() alloc regardless of n_preallocs, because
as i wrote in the original email, if the chunks/objects are too large,
g_slice_*() wil delegate to malloc anyway.
---
ciaoTJ
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]