STL Efficiency
Author
I know there about a bazzillion and one threads on the subject already extant, but the only ones I could find that directly addressed my question were several years old, and the consensus seemed to be that the then current version of STL provided by Visual Studio was highly inefficient.
I'm reading a book on programming, and it says that game programming (more for consoles than PCs) should avoid use of STL because it's very nasty on memory. Given that my understanding was that STL had been highly optimized and tested and was highly efficient, this took me by surprise. Is the book feeding me wrong (or outdated) information, or did I take a serious right-turn somewhere in my understanding of things?
What about this wonderfully recent discussion?
And the obligatory:
EA STL
And a discussion of what we've built on at my work:
Here
STL is efficient at providing you with exactly what the specs say it does. This may or may not be the fastest you can achieve. But STL also provides you with many of the tools you need to adapt it. Because the "general" case is more useful, you should start with it, profile, and then see where your problems are.
For the memory thing in question, you can provide custom allocators, and you can curb the cost of allocation by reserve()-ing memory ahead of time if you know the end size of the container.
And the obligatory:
EA STL
And a discussion of what we've built on at my work:
Here
Quote:
Given that my understanding was that STL had been highly optimized and tested and was highly efficient, this took me by surprise.
STL is efficient at providing you with exactly what the specs say it does. This may or may not be the fastest you can achieve. But STL also provides you with many of the tools you need to adapt it. Because the "general" case is more useful, you should start with it, profile, and then see where your problems are.
For the memory thing in question, you can provide custom allocators, and you can curb the cost of allocation by reserve()-ing memory ahead of time if you know the end size of the container.
Author
I tried searching... <blush> The irony is I think I even saw the discussion a while back in a random forum browse.
Sorry!
Sorry!
Just make sure that you can establish that STL is the problem before attacking it. If you have a portion of code that needs to be called 1000x per second, then yeah, scrutinize over whether STL would harm you in that situation. If you are worried about using STL in the code that loads a level (an inherently "slow" portion of code that no one cares if it takes a little while), then you need to relax. Don't waste time reinventing the wheel if you don't know how to make a better wheel.
You should just be aware of how the STL containers work under the hood.
e.g. These 3 blocks generate the same result (a vector of the numbers 0 through 1M), but the number of allocations / checks is quite different for each:
Another thing about games is that sometimes you want to be specific about which part of memory things are allocated within; you can use custom STL allocators to achieve this (though they aren't perfect -- see EASTL).
Lastly, MS enables some STL debugging even in release builds by default. For high-performance code on MSVC++, look into _SECURE_SCL
e.g. These 3 blocks generate the same result (a vector of the numbers 0 through 1M), but the number of allocations / checks is quite different for each:
const static int BIG = 1000000;{ std::vector<int> vecNumbers; for( int i=0; i<BIG; ++i ) vecNumbers.push_back( i );}{ std::vector<int> vecNumbers(BIG); for( int i=0; i<BIG; ++i ) vecNumbers = i;}{ std::vector<int> vecNumbers; vecNumbers.reserve(BIG) for( int i=0; i<BIG; ++i ) vecNumbers.push_back( i );}Another thing about games is that sometimes you want to be specific about which part of memory things are allocated within; you can use custom STL allocators to achieve this (though they aren't perfect -- see EASTL).
Lastly, MS enables some STL debugging even in release builds by default. For high-performance code on MSVC++, look into _SECURE_SCL
Author
Quote:Original post by TheBuzzSaw
Just make sure that you can establish that STL is the problem before attacking it. If you have a portion of code that needs to be called 1000x per second, then yeah, scrutinize over whether STL would harm you in that situation. If you are worried about using STL in the code that loads a level (an inherently "slow" portion of code that no one cares if it takes a little while), then you need to relax. Don't waste time reinventing the wheel if you don't know how to make a better wheel.
I'm right now I'm more focused on building my programming 'toolkit', and less on specific applications (though I have plenty of those floating around I need to work on; a game for my senior project that isn't going well, a loan calculator for my part time job, and some 'skill building' exercises I set myself that I still need to get around to...).
Quote:Original post by Rilbur
I know there about a bazzillion and one threads on the subject already extant, but the only ones I could find that directly addressed my question were several years old, and the consensus seemed to be that the then current version of STL provided by Visual Studio was highly inefficient.
I'm reading a book on programming, and it says that game programming (more for consoles than PCs) should avoid use of STL because it's very nasty on memory. Given that my understanding was that STL had been highly optimized and tested and was highly efficient, this took me by surprise. Is the book feeding me wrong (or outdated) information, or did I take a serious right-turn somewhere in my understanding of things?
This topic has been discussed to death, but I'll add something none the less:
The only way to make STL implemented things more efficient is to add additional constraints, making the implementation less general. So, it is not a good idea to replace STL everywhere, but it may be a good idea to replace it where a more efficient implementation is needed and possible.
Quote:Original post by Rilbur
There are 10 types of people in the world:
Those that understand binary, and those that don't.
There are 10 types of people in the world:
Those that understand binary,
those that understand ternary,
those that understand quaternary,
[...]
those that understand n-ary,
[...]
and those that don't.
Author
That's more amusing than the last guy to pick my sig apart, who pointed out that you only needed one bit to keep track of the types of people, a simple 'true / false' flag.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
