[systemd-devel] [PATCH 21/26] hashmap: rewrite the implementation

[Lennart Poettering]

On Tue, 21.10.14 17:50, Michal Schmidt (mschmidt at redhat.com) wrote:

> >> +static struct HashmapBase *__hashmap_new(const struct hash_ops *hash_ops, uint8_t type  HASHMAP_DEBUG_PARAMS) {
> >> +        HashmapBase *h;
> >> +
> >> +        h = malloc0(all_hashmap_sizes[type]);
> >> +        if (!h)
> >> +                return NULL;
> >> +
> > 
> > Hmm, a malloc() for each hashmap we allocate? Isn#t that prohibitively
> > expensive given how slow malloc() is? We have soo many hashmaps!
> 
> Is it really that slow? A small test program that does malloc(48) ten
> million times (no freeing) runs for about 0.3 seconds on my laptop.
> systemd allocates about 2000 hashmaps here. So these would take about
> 60 microseconds to malloc. Maybe the test program has it too easy due
> to having to deal with no heap fragmentation. But then I'd expect the
> allocations this small to be helped by glibc's fastbins...
> I guess I'll take some measurements under qemu with no KVM :-)

Hmm, I did my testing back in callgrind back when I optimized systemd
a bit, and malloc() was by far the most expensive call of all. After
adding the allocation cache for hashmap items it was much better, but
still at the top of things. I then added an allocation cache also for
the hashmap heads themselves and everything appeared good enough to
me, and malloc() was not the most expensive call anymore (and the
allocation cache was neither...)

Would be interesting to run systemd in callgrind again with a
non-trivial number of units and see what costs these days. My last
callgrind optimizations I did years back now, things might have
changed quite a bit.

Lennart

-- 
Lennart Poettering, Red Hat