News for hackers. Stuff that matters.
Re:Benchmarking C++ Allocators by userbinator on Monday April 27, 2020 @08:39PM (#23002010)
This. Before trying to make allocation faster, try to eliminate them first. A lot of code I've seen in higher-level languages, even (or especially?) most C++, seems completely oblivious to the amount of memory manipulation they're doing.

"The fastest way to do something is to not do it at all."

A related old article about how Chrome's "omnibox" would do 25k allocations on each keystroke: https://news.ycombinator.com/item?id=8704318

Re:Benchmarking C++ Allocators by oddity on Tuesday April 28, 2020 @02:23AM (#23004038)
> even (or especially?) most C++

C++ hits the particularly nasty sweet spot of hiding boilerplate just enough that you have no idea what you're actually calling while also not having a sophisticated JIT that can do escape analysis and other tricks to optimize that kind of code.

It doesn't help that, often, the default response to not having a clear understanding of resource ownership in a code-base is to make a copy.

I also find that people struggle to internalize the costs of memory allocation. These days, the default allocators on modern systems are fairly well tuned for crap code, and the cost of any one particular allocation is a complicated function of all the allocations that came before it. They're different orders of magnitude in the badness scale, but any one allocation never looks so bad, just like any one memory load/store never looks so bad.

Re:Benchmarking C++ Allocators by MaxBarraclough on Tuesday April 28, 2020 @05:52AM (#23005360)
> Before trying to make allocation faster, try to eliminate them first

Not sure if memory pools still count as allocation, but they should be faster, and are easily done in C++. Boost.Pool for instance.