He says "use smart pointers, if you have to" at around 1:33.
But anyway, if performance matters at all you shouldn't heap-allocate in any hot code path in the first place. E.g. if memory management overhead is showing up in profiling, don't start looking for a faster general-purpose allocator, but instead rethink your memory management strategy ... and "I'll just put every C++ object behind a smart pointer" isn't really a memory management strategy ;)
Yes. The main problem with the talk is that it's just too general. It gives good advice, but it's only really good advice if you understand what it's trying to say, at which point you don't need the advice. Kinda impossible to cover "what every programmer needs to know" in 5 minutes.
So, "use smart points, if you have to", should have been: "if you need to allocate memory dynamically, use smart pointers".
As always the answer is "it depends". Smart pointers kind of 'encourage' that each C++ object lives in its own heap allocation, but this quickly becomes a problem if you deal with tens- or hundreds-of-thousands of small C++ objects that way, each in its own heap allocation, and on top a high number of those objects being frequently created and destroyed (for instance with std::make_unique or std::make_shared). I call this a "Java-style C++ code base".
Technically this works and it's reasonably safe, because RAII takes care of memory management, just like GC takes care of memory management in Java.
But the problem there is deeper: it's not smart pointers vs raw pointers, but that each small object lives in its own heap allocation.
That's the typical scenario where you will see memory management becoming a performance problem (for at least two reasons: (1) heap allocation and especially deallocation isn't free, and (2) lots of cache misses when accessing objects that are spread more or less randomly over the address space).
Ideally you'd group many similar objects into long-lived and compact arrays, process the data in those arrays in tight loops, minimize pointer indirections, and minimize allocations (ideally you'd only allocate those arrays once at program start, or when those arrays need to grow). Once you did all those things, memory managament suddenly becomes a non-problem (because you only have a handful of long-lived allocations to care about), and RAII becomes a lot less useful (because the 'objects' in those arrays will most likely just be C-style plain-old-data structs). This is basically the 'antithesis' to OOP. And before you know it you're back to writing C code, like it happened to me ;P
TL;DR: there is no silver bullet for automatic memory management if performance matters.
I might be totally missing something here, but wouldn’t using raw pointers include using new/delete, so all those small C++ objects would also live on the heap.
Are you saying smart pointers and there overhead make the heap allocations even bigger and that’s the cause of the cache misses?
You might want to watch "GoingNative 2013 C++ Seasoning" video or at least check it's slides [1]. It may sound like it is old but the part about pointers is essential for anyone who wants to write C++.
IMHO from gamedev: HN is not going to get it ever. They either have moved to high level languages or do not need performance at all.
His larger point was having a focus on memory management. He mentioned new and delete in reference to ensuring they match up to avoid memory leaks. He also mentioned smart pointers.
If you wanted every drop of CPU performance, you probably wouldn’t be doing lots of memory allocation. You would probably look at every operation in your critical path/loop and ask 1) do I have to do this at all? 2) do I have to do this right here/now?
Cut out, defer, pre-allocate until you get as fast as you can.
I would imagine that nowadays you should use new/delete only if you have to account for every CPU cycle to literally get every drop of performance...