3 ms·

And this is why C++ can still be fast, even when the common STL implementations are a steaming pile performance-wise. The naturally developed style has been one

And this is why C++ can still be fast, even when the common STL implementations are a steaming pile performance-wise. The naturally developed style has been one-reference-only, so a lot of this never has to get done. With Objective-C, anything that isn't C is on the heap and reference counted. Even Java can allocate objects on the stack in tight loops (though this is done by the JIT, not by a change in how variables are declared).

TillE 12y ago
What parts of modern, popular STL implementations are notably slow? The only issue I've ever had is the blatantly obvious one of reallocating std::vector as it grows. You really want to reserve() enough space in advance if at all possible, because copying large chunks of memory is not fast.
- yoklov 12y ago
  You don't always get to use a modern, popular STL. Sometimes you need to use the hardware vendor's crappy, unoptimized STL (because they assume you won't use it). This is part of the reason the STL is unpopular in game development, though the story here has been getting better. To answer your question, in my experience when the standard doesn't mention the desired performance characteristics of a function or method, even the popular STLs (libstdc++ and libc++ certainly) optimize for maintainability over performance. Not sure I can pull up an example of this right now but they are numerous. A good place to start is the standard containers other than deque or vector. A bigger issue IMO is that the existence of some methods in various standard classes/templates really murder performance, no matter how good the implementation is. One particularly bad example is the bucket() method, local_iterator types, etc. in c++11's unordered_map (probably the rest of the unordered family too). These force the table to be implemented in such a way that every insertion requires a heap allocation, and iteration requires much more pointer chasing than would otherwise be necessary (e.g. with a probed implementation), which is... unfortunate for the cache.

TillE 12y ago

What parts of modern, popular STL implementations are notably slow? The only issue I've ever had is the blatantly obvious one of reallocating std::vector as it grows. You really want to reserve() enough space in advance if at all possible, because copying large chunks of memory is not fast.

yoklov 12y ago
You don't always get to use a modern, popular STL. Sometimes you need to use the hardware vendor's crappy, unoptimized STL (because they assume you won't use it). This is part of the reason the STL is unpopular in game development, though the story here has been getting better. To answer your question, in my experience when the standard doesn't mention the desired performance characteristics of a function or method, even the popular STLs (libstdc++ and libc++ certainly) optimize for maintainability over performance. Not sure I can pull up an example of this right now but they are numerous. A good place to start is the standard containers other than deque or vector. A bigger issue IMO is that the existence of some methods in various standard classes/templates really murder performance, no matter how good the implementation is. One particularly bad example is the bucket() method, local_iterator types, etc. in c++11's unordered_map (probably the rest of the unordered family too). These force the table to be implemented in such a way that every insertion requires a heap allocation, and iteration requires much more pointer chasing than would otherwise be necessary (e.g. with a probed implementation), which is... unfortunate for the cache.