Re: [PATCH v2] Add malloc micro benchmark

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

On 02/28/2018 06:16 AM, 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.  Of course, there are
> workloads where it loses big, but those exist for other allocators,
> too.  People simple don't write blog posts comparing *alloc with
> glibc malloc if glibc malloc provides comparable or better
> performance because it's quite boring.
> 
> 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?

I agree.

I think an incremental improvement would be to start with some further
code cleanups, all with the goal of simplifying the allocator maintenance.

Getting rid of unsorted bins would be interesting. One of the problems I
see is that without changes in our data structures and algorithms it is hard
for a heap-style allocator to keep a bound on the total amount of heap consumed.

One of the big requirements that I see coming down the pipe is to provide an
allocator that has bounded memory usage. To do that we'd have to track all of
the unsorted blocks, free blocks, consolidate more regularly, and free against
the heuristic which tells us how much memory to keep cached. If having got rid
of unsorted makes this easier, if having a balanced binary tree makes this
easier, then that's where we should be looking.

-- 
Cheers,
Carlos.