Re: [PATCH v2] Add malloc micro benchmark

[Ondřej Bílka <neleai at seznam dot cz>]

On Wed, Feb 28, 2018 at 03:16:09PM +0100, Florian Weimer wrote:
> On 02/28/2018 03:11 PM, Ondřej Bílka wrote:
> >Thats rather ineffective, it is easier to start fresh than try to
> >maintain rather obsolete allocator. Most of other are faster and more
> >space effective because of their layout.
> 
> That's not quite true.  Despite its limitations, glibc malloc still
> compares remarkably well to other allocators.

That confuses cause and effect. People spent lot of effort to fix
workloads where this allocator is bad (usually starts with saying that
malloc is slow) with trick like static buffers, merging allocations, memory pools etc. 
With better allocator it wouldn't be neccessary as it would handle simpler 
code with same performance. 
> 
> I think a heap-style allocator which does not segregate allocations
> of different sizes still has its place, and why not provide one in
> glibc?
>
That isn't case for any allocator and it is asking for trouble. You want
to avoid sitation where two big chunks couldn't be merged because of
tiny chunk between them. 
Also you will likely spend more space on header overhead than could you save.
For small sizes merging chunks doesn't happen so we lose nothing by
requiring uniform capacity. 

For larger size this representation is still problematic and you could
improve performance with another representation that also avoids
alignment problem by placing metadata elsewhere(for mine only 4 bytes are needed).