CODEWITHSUNDEEP
stl
qwerty
qwerty

Reputation: 373

"home-brew" STL for performance?

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 ;) )

Upvotes: 4

Views: 1139

Answers (8)

MissT
MissT

Reputation: 780

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.

Upvotes: 2

Matthew Olenik
Matthew Olenik

Reputation: 3577

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.

Upvotes: 1

Martin Beckett
Martin Beckett

Reputation: 96139

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

Upvotes: 1

amit kumar
amit kumar

Reputation: 21022

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

Upvotes: 1

Mark Ransom
Mark Ransom

Reputation: 308364

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.

Upvotes: 1

Adrian Grigore
Adrian Grigore

Reputation: 33318

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; 
}

Upvotes: 10

i_am_jorf
i_am_jorf

Reputation: 54600

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.

Upvotes: 6

Alex Fort
Alex Fort

Reputation: 18821

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.

Upvotes: 1

Related Questions