Re: about glibc performance

[Carlos O'Donell <codonell at redhat dot com>]

On 3/22/19 5:38 PM, Eric Wong wrote:
> Jimmie <zpjjimmie@163.com> wrote:
> > Hi, For serveral days, I did some test  about the memory
> > performance of glibc(2.17) and tcmalloc(gperformance 2.7), and my
> > test results indicate that glibc is more efficient then tcmalloc. 
> > generally, people think tcmalloc is efficient than glibc 2.3, but I
> > use glibc 2.17, so I wonder if glibc 2.17 did some improvement on
> > memory performance. looking forward to your reply, thank you.
>
> You may also want to check out my proof-of-concept wfcqueue patch 
> which optimizes message passing:
>
> https://public-inbox.org/libc-alpha/20180731084936.g4yw6wnvt677miti@dcvr/
>
>  Unfortunately, integrating wfcqueue/URCU into glibc will take much
> effort :<

FAOD I really like the direction these patches take glibc's malloc.
I just don't have time to push your idea to completion. I know it's
a lot of effort to push novel ideas forward, but it touches
pieces of code which are used by a lot of programs. The best tooling
we have today is malloc trace/simulation to capture and compare
workloads before and after:
https://pagure.io/glibc-malloc-trace-utils

So the hard part is not the changes to the code, but it's in doing
the before/after performance comparison for a variety of workloads
and capturing those workloads with the tracer so others can look
at and run them. We don't even have a good place to store large
workloads (we're talking to overseers to see if we can enable some
git-annex support on sourceware, git lfs is still too new).

--
Cheers,
Carlos.