Hacker News Reader

Comment by titzer | Hacker News Reader

I've seen internal numbers from $MEGACORP that suggest large-scale C++ applications spend 15-20% of their time doing memory management. Incidentally, the memory fragmentation on those same applications can end up as high as 40%. In GC'd languages fragmentation is typically closer to 10%.

View on HN

This paper gives 10% for allocation in Google's fleet, and that was before significant efficiency improvements in tcmalloc. https://static.googleusercontent.com/media/research.google.c...

Thanks for the link. I am going by ballparks I've heard internally, from less than 3 years ago (so, with newer allocators), and unfortunately can't provide a reference. It would be great if there was more public information from large-scale studies.

https://research.google/pubs/pub50370/ gives more up to date information, as does the slide deck here: https://docs.google.com/presentation/d/1taP_gqeRE1XGB2td7f32... (We get down to 4% on the graph on slide 3.)

It's far below 10% now (thanks to the hard work of a lot of people), and Google actually gotten to the point where we chose to spend _more_ time in malloc to make overall efficiency higher.

You can spend literally as much time as you like on memory management. Google has chosen 20%. They have also, by banning exceptions, chosen to spend a very substantial part of their time on checking for error status, and on two-phase initialization and cleanup.

I most typically choose 0% post start-up, with 0% fragmentation. For a different problem domain, I might choose differently.

So you're running programs without dynamic memory allocation? That makes sense for a certain domain, like microcontrollers and embedded systems, but most programs do end up dynamically allocating memory, which leads to non-zeroes for both of those things.

My programs mmap thousands of hugepages at startup, then run for years. Well, not all of them.

Reply on news.ycombinator.com