3 ms·
> often going to be tons cheaper than doing the manual memory management. And on top of that, manual memory management is not free. I maintain a simple but hig
by obstinate 11y ago
> often going to be tons cheaper than doing the manual memory management.
And on top of that, manual memory management is not free. I maintain a simple but high-throughput C++ server at Google, and tcmalloc is never less than 10-15% of our profiles.
Don't get me wrong, I'm not saying that Go is faster than C++ or ever will be. I'm just trying to counter the notion that "GC is expensive, manual memory management is near zero runtime cost."
- jblow 11y agoI bet that if someone who knew what they were doing decided to optimize that, you'd get the cost WAY down, possibly almost to zero. (If you are using std::string, that is your problem right there). But the very important difference here is that in your case you have a choice and it is possible to optimize the cost away and to otherwise control the characteristics of wheyou pay this cost. In GC systems it is never possible to do this completely. You can only sort of kind of try to prevent GC. It's not just a difference in magnitude, it's a categorical difference.
- reagency 11y agoIf you really really want to, you can allocate a buffer for all your data.
- obstinate 11y agoThis solves little. What do you think the system allocator is doing under the covers?
- SamReidHughes 11y agoIt's doing a lot less, if you're allocating one buffer for your data instead of many.
- obstinate 11y agoPerhaps. The team is a group of seasoned veterans of high performance server engineering. But perhaps there are others who could improve on our efforts by a significant margin. Of course we do not use std::string.
- SamReidHughes 11y agoJust curious: Have you tried jemalloc, and what numbers did you get?
- obstinate 11y agoWe haven't. Google infrastructure uses tcmalloc. Is there a reason to believe it offers a significant win?
- SamReidHughes 11y agoI'd expect similar performance but less fragmentation?, less memory used by the process if you aren't regularly calling MallocExtension::instance()->ReleaseFreeMemory() as a tcmalloc user. The first answer at https://www.quora.com/Is-tcmalloc-stable-enough-for-production-use https://www.quora.com/Is-tcmalloc-stable-enough-for-producti... (by Keith Adams) is completely consistent with what I've seen. Rust went with jemalloc for some reason too.
- Jweb_Guru 11y agoIIRC jemalloc is somewhat better about releasing memory in a timely fashion, at least by default.