"home-brew" STL for performance ?

Question

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html

According to that article STL isn't suited for game-development. What are your thoughts about this ?

My current approach is this : use STL, if leads to performance problems exchange with homebrew container (or allocator) (didn't come to it yet, but I'm not doing a high-end 3d game ;) )

Answer 1

Your approach is the only sane option in this case. Rule #1 for optimization is "do not optimize unless you know exactly where the bottlenecks are".

You should still be able to swap your container relatively easily later on, especially if you use a type defined via typedef instead of directly using the STL container. I mean something like:

#include <vector>

typedef std::vector<int> MyIntVectorType;

int main()
{
   MyIntVectorType theVector; 
}

Answer 2

Use STL, and if it works within an acceptable performance range, keep it. If not, try something else. You don't want to be re-writing something that already exists before you try the existing implementation.

Answer 3

You have to be aware of what STL is doing under the covers. For example, if you use a vector, for example, don't just let it grow arbitrarily, use vector::resize() to do the allocation up front so it only allocates once. Stuff like that. Your approach isn't bad—just do your homework.

Answer 4

Many of the performed-related problems in C++ have been fixed in C++0x.

Answer 5

You may want to look at something like EASTL, designed specifically for games.

Edit: Apologies, I thought the link in the question was a different article.

Answer 6

Sometimes it's not the container that needs replacing, it's the contained object. I once had a large std::map that had a string for a key, and it was too slow. I realized that all of my keys were the same size, so I replaced the string class with a specialized version that I wrote as a wrapper around a fixed-size char buffer, and performance was no longer an issue.

Know where your bottlenecks are, and don't assume you can write a faster version of anything unless there are huge simplifying assumptions you can make.

Answer 7

You can also swap the allocator in STL containers for a custom one.

Answer 8

If you are just starting with game programming, go on and use STL, it's great and it's stable. You are better off with something that works and is stable than to start scratching for a fps or two. However, here are the two reasons why many major studio don't use it.

• At some point, you'll want to push your system to the limit. If your engine is very large, optimizing container is a good way to gain everywhere (graphic, audio, physics, etc.). Optimizing with assembly, having different implementations of a container for different use will become a must. Templates aren't the leanest implementation ever.
• STL have a different implementation on different plateforms (PS2, PS3, Wii, 360, PC etc.). If you are working crossplatform, sometimes those differences will create problems at the very root of your system, in the supposed "all-plateform code". When this happened to you once, you will want to move to something that you will be able to maintain in an easier way.

Having a custom version of container isn't a trivial job, do it only if it's worth it.