3 ms·

Hmm... if the allocator affects performance so much, then maybe the code simply uses the allocator too frequently? In C++, if someone starts frantically search

Hmm... if the allocator affects performance so much, then maybe the code simply uses the allocator too frequently? In C++, if someone starts frantically searching for a faster general purpose allocator then it's usually a sign of putting each C++ object into its own heap allocation behind a smart pointer, creating and destroying tiny objects all the time, and then wondering why so much time is spent in the allocator.

a_humean 3y ago
Not sure its right to blame the code when changing the base image/allocator results in 30x performance improvements on the same hardware. I would be inclined to blame a poor choice of base image/allocator.
- croemer 3y ago
  It's not a docker thing, we're getting the same 30x performance hit without using docker, simply compiling musl vs glibc binaries with the default allocator chosen by Rust.
croemer 3y ago
Every optimization that you don't need to do is a win. With glibc, performance impact of unnecessary allocations might be minimal, but with musl allocations suddenly matter a lot.
the_mitsuhiko 3y ago
> Hmm... if the allocator affects performance so much, then maybe the code simply uses the allocator too frequently? I'm not familiar with musl's allocator so it's hard for me to say anything about it. However what is pretty common is that modern allocators use thread local allocators to avoid hammering global locks too much. Since Rust is very concurrent you don't need too many allocations to benefit from these optimizations.
wredue 3y ago
In a lot of ways, rust definitely encourages heavy use of allocator. Even if you program better for it, one of the prevailing opinions on “learning about lifetimes” is to “not learn lifetimes, just make copies”.
hayley-patton 3y ago
If the allocator can't keep up with the code, then maybe the allocator simply is bad?
lmm 3y ago
> putting each C++ object into its own heap allocation behind a smart pointer, creating and destroying tiny objects all the time Are C++ allocators so bad that they can't handle this use pattern? Yes, you can make a bunch of manual effort to use the allocator less, but you shouldn't have to.

a_humean 3y ago

Not sure its right to blame the code when changing the base image/allocator results in 30x performance improvements on the same hardware. I would be inclined to blame a poor choice of base image/allocator.

croemer 3y ago
It's not a docker thing, we're getting the same 30x performance hit without using docker, simply compiling musl vs glibc binaries with the default allocator chosen by Rust.

croemer 3y ago

Every optimization that you don't need to do is a win. With glibc, performance impact of unnecessary allocations might be minimal, but with musl allocations suddenly matter a lot.

the_mitsuhiko 3y ago

> Hmm... if the allocator affects performance so much, then maybe the code simply uses the allocator too frequently? I'm not familiar with musl's allocator so it's hard for me to say anything about it. However what is pretty common is that modern allocators use thread local allocators to avoid hammering global locks too much. Since Rust is very concurrent you don't need too many allocations to benefit from these optimizations.

wredue 3y ago

In a lot of ways, rust definitely encourages heavy use of allocator. Even if you program better for it, one of the prevailing opinions on “learning about lifetimes” is to “not learn lifetimes, just make copies”.

hayley-patton 3y ago

If the allocator can't keep up with the code, then maybe the allocator simply is bad?

lmm 3y ago

> putting each C++ object into its own heap allocation behind a smart pointer, creating and destroying tiny objects all the time Are C++ allocators so bad that they can't handle this use pattern? Yes, you can make a bunch of manual effort to use the allocator less, but you shouldn't have to.