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?
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.
reply