Re: GSlice with tight memory (Re: Help Needed)

[Soeren Sandmann <sandmann daimi au dk>]

Tim Janik <timj imendio com> writes:

> > In general, I'd recommend just always using
> >
> >        g_slice_set_config (G_SLICE_CONFIG_ALWAYS_MALLOC, 1);
> >
> > This way the various tools, valgrind and memprof, will work with your
> > application, and you don't get any surprises with pathological cases
> > causing run-away caching. The speed difference between g_slice and
> > g_malloc is basically noise as soon as you include the time to
> > initialize the new block of memory.
> 
> in general? that is certainly bogus, if what you said was true, there'd
> be no point in having GSlice in the first place. 

I don't think there was any point in having GSlice in the first
place.

> do you have any benchmark (data) that backs up your claims?

Just add initialization of the memory to glib/tests/slice-test.c, and
any real speed difference vanishes. I don't have the patch anymore.

Even without initialization, there is just not that much of a
difference. On my laptop I just got:

GSlice, one thread:             0.23.01 elapsed
malloc, one thread:             0.23.11 elapsed
GSlice, four threads:           1.32.71 elapsed
malloc, four threads:           1.31.62 elapsed

For slice-color, which does touch the allocated memory, I get:

GSlice, color incr 1:         14.47s
GSlice, color incr 3:         13.84s
malloc:                       14.01s
malloc, run 2:                13.92s

None of this indicates that any of the two allocators is faster than
the other. Most importantly, there is no indication that it matters in
the real world.

Except for higher i-cache load and bugs complaining about pathological
caching with GSlice, that is.


Soren