CppCon 2016: Nicholas Ormrod “The strange details of std::string at Facebook"
Why Hacker News recommends it
HN returns to it as the go-to talk on string internals, small string packing and why small percentage optimizations matter at scale.
What it is
Nicholas Ormrod's CppCon 2016 talk on how Facebook optimizes std::string with its open-source replacement fbstring. It covers storage layout tradeoffs, small string optimization and memory allocation behavior.
Recommended by 4 HN commenters across 4 different months, 2018 to 2026.
What Hacker News said
Recommends pjscott · 2020-01 · on “Libc++'s Implementation of std::string”
I think this is the talk you're referring to. If not, it's still definitely worth a watch: [this video]
Recommends jiggawatts · 2024-03 · on “Algorithms for Modern Hardware”
The FAANGS certainly have people doing this kind of work. For example, Andrei Alexandrescu has a bunch of keynote talks at CPPCon where he talks about 1-4% speed optimisations he makes to the std library at Facebook. [LINK] I also like the talk by Nicholas Ormrod “The strange details of std::string at Facebook": [this video]
Recommends D4ckard · 2024-12 · on “Fixing C Strings”
Yes, there are really cool packing techniques. See this talk for example: [this video] I don't include the null-terminator because I use this type in my own environment where I never use null-terminated strings so there is no need for it.
Recommends def-pri-pub · 2026-03 · on “Faster Asin() Was Hiding in Plain Sight”
You'd be surprised how it actually is worth the effort, even just a 1% improvement. If you have the time, this is a great talk to listen to: [this video] For a little toy ray tracer, it is pretty measly. But for a larger corporation (with a professional project) a 4% speed improvement can mean MASSIVE cost savings. Some of these tiny improvements can also have a cascading effect. Imagining finding a +4%, a +2% somewhere else, +3% in neighboring code, and a bunch of +1%s here and there. Eventually you'll have built up something that is 15-20% faster. Down the road you'll come across those optimizations which can yield the big results too (e.g. the +25%).
Cites 3uclid · 2018-04 · on “Show HN: SuperString – A fast and memory-optimized string library for C++”
Side note: FB also developed a string library to replace std::string ( [LINK] ). Here's a video from explaining the motivation behind the project ( [this video] ).
Cites GolDDranks · 2018-07 · on “Pointers Are Complicated, or What’s in a Byte?”
I'm not going to take the responsibility whether it's correct or not - here's the talk I learned it from: [this video]
Cites jiggawatts · 2023-03 · on “Analyzing multi-gigabyte JSON files locally”
You're all massively underestimating the memory requirements of a parsed data structure, which is very entertaining to watch. There's this rule-of-thumb that most programmers are wrong about performance costs by at least a couple of orders of magnitude, and it's on full display here. In most languages, dynamically allocated variable-sized objects have a minimum overhead of two pointer-sized fields: a pointer and a length. On a 64-bit platform, that's 16 bytes before you actually start having any data. Next, depending on the allocator used, the requested data size is probably rounded up, either to the next power of 2, or there may be a minimum allocation size of 1 pointer. That's "safe" on ma
Cites nyanpasu64 · 2023-10 · on “Why Async Rust?”
Can you have the runtime run a job every second, to trim thread stack depths and return memory to the kernel (whatever was meant by [this video] ) while holding a FFI mutex (or a sharded one), and have every C function call first lock the mutex and expand the stack to the necessary depth?