[inetknght]

> these days there is no reason to cache and reuse allocations.

No, you are wrong. Ideas like that are a big reason that apps get slower despite hardware getting faster.

[asveikau]

I think it becomes an application specific or domain specific thing.

For example, I've done some work with audio or video. Nobody working on that goes straight to malloc on every packet or frame. It'd just be asking for pain.

But a general purpose allocator doing its own free-list on the assumption that libc is going to suck? I think that's outdated. If you do want to support it, I think it's better to allow the caller to replace the allocator through a function pointer, rather than just do it by default in a library.

[TingPing]

glib does not always use one, the default is normal malloc and it provides another allocator api as an option.

[asveikau]

Yes, I figured that out from other posts on this thread (including one where I looked at g_malloc source).

I think libstc++ on the other hand does or did have such a cache as an always-on thing though. So not unheard of.

[stretchcat]

Isn't the right way of doing this to use a different implementation of malloc, rather than wrapping malloc with your own meta-malloc?

[inetknght]

> Isn't the right way of doing this to use a different implementation of malloc, rather than wrapping malloc with your own meta-malloc?

Yup [0].

There's even other complete libraries like tcmalloc [1] and jemalloc [2].

[0] https://stackoverflow.com/a/262481/1111557

[1] https://github.com/google/tcmalloc

[2] https://github.com/jemalloc/jemalloc

[saagarjha]

One reason I can think of wrapping malloc is that C is more likely to give you that than whatever OS-specific API you are going to use to get memory from the kernel (if you even have one!).