about glibc performance

[Siddhesh Poyarekar]

That's really cool, thanks for doing this!  Is this the latest glibc
or glibc-2.17?  Also, is tcmalloc the latest one too?

As for glibc improvements, there are spikes in
bench_fastpath_stack_simple(8192) and
bench_fastpath_rnd_dependent(8192) that may be worth looking into.

Siddhesh

On Tue, 26 Mar 2019 at 07:50, Jimmie <zpjjimmie@163.com> wrote:
>
> I agree that it's not a sufficient enough test, so I also use the benchmark from https://github.com/gperftools/gperftools/tree/master/benchmark, which is provided by google.
> I also had the test result and attach to the attachment. You can download it and maybe you should open it with nodepad++ or some else to typeset nicely.
>
> Thanks.
> Jimmie
>
>
> At 2019-03-25 17:46:51, "Siddhesh Poyarekar" <siddhesh.poyarekar@gmail.com> wrote:
> >On Mon, 25 Mar 2019 at 13:11, Jimmie <zpjjimmie@163.com> wrote:
> >>
> >> It seems like that I can't send attachment to libc-help. so I simply describe my test results.<br/>malloc and free 10000 times in per-thread, the datas is below(left column represent memsize per malloc. and the other column represent the cost time it uses, )
> >
> >Thank you for sharing your results.  While the results are very
> >tempting to share (because of my obvious bias as a glibc developer),
> >simply allocating and freeing repeatedly in per-thread may not be a
> >sufficient enough test.  This does show that glibc does significantly
> >better than tcmalloc for same size reallocations, but not much else.
> >That is unless you're baking in a way to mix up the sizes and
> >allocations that mimic some known real world workload(s).
> >
> >If you're interested in pursuing this further, I would recommend
> >profiling a program like firefox or libreoffice to find
> >malloc/calloc/realloc/free calls and then mimicing that workload
> >somehow.  That would be a much nicer benchmark to do this kind of
> >comparison.
> >
> >Thanks,
> >Siddhesh
>
>
>
>
>
>
> --
> Jimmie



-- 
http://siddhesh.in