Re: [patch] malloc per-thread cache ready for review

[DJ Delorie <dj at redhat dot com>]

Markus Trippelsdorf <markus@trippelsdorf.de> writes:
> Using google turns up several examples.

The trace capture and simulation tools are in the dj/malloc branch,
please feel free to ask Facebook to capture their workload so we can
benchmark our malloc changes against them...

(only partly joking here, I'll happily accept a trace from them, and
it's the only way to make sure their interests are represented in our
work)

> I have mentioned compile times of C++ projects. Here an alternative
> allocator typically decreases build times by 6-8% (I have measured this
> myself).

If you can reproduce those measurements with a captured workload, that
would be a useful addition to our corpus.  Yes, I could do it myself,
but that doesn't guarantee I'm testing the specific inputs and
environment you have, which a workload captures for me.

Hmmm... "send me a workload" is going to be my default response to
malloc performance questions from now on, I think...

> More likely the multi threaded nature of modern browsers requires a
> better allocator.

Yes, glibc's malloc design pre-dates the popularity of multi-threaded
apps, and we've been playing catchup.  Our hot path is very long
compared to other allocators, which is why I chose the tcache as a first
attempt at shortening it.

> In this case DJ's per-thread cache patch would help, I guess.

The whole point of capturing workloads is to eliminate the "I guess".
Let's get a workload and find out if it helps or not :-)