3 ms·

> 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 getti

> 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.

stretchcat 6y ago
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 6y ago
  > 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 https://stackoverflow.com/a/262481/1111557 [1] https://github.com/google/tcmalloc https://github.com/google/tcmalloc [2] https://github.com/jemalloc/jemalloc https://github.com/jemalloc/jemalloc
  - saagarjha 6y ago
    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!).
asveikau 6y ago
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 6y ago
  glib does not always use one, the default is normal malloc and it provides another allocator api as an option.
  - asveikau 6y ago
    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.

> 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.

stretchcat 6y ago

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 6y ago
> 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 https://stackoverflow.com/a/262481/1111557 [1] https://github.com/google/tcmalloc https://github.com/google/tcmalloc [2] https://github.com/jemalloc/jemalloc https://github.com/jemalloc/jemalloc
- saagarjha 6y ago
  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!).

asveikau 6y ago

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 6y ago
glib does not always use one, the default is normal malloc and it provides another allocator api as an option.
- asveikau 6y ago
  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.