This is a common query and I doubt anyone has the definitive answer because what was once known as STL covers quite a wide range of concepts. Likely any one individual has only a very limited use for and knowledge of a subset of it, even if that's a large subset. I don't think it's possible for anyone to really be an expert across the entire STL because I doubt any single person has used every single feature.
It's important to understand this...because people should expect quite a varying range of opinions and you need to consider the subset of functionality that is relevant to your own work. For game development, we’re really only talking about a few specific types of containers that are relevant to run time. Tools are fair game for a much wider range of needs.
Once upon a time, at least to settle this query for my own purposes I considered the subset that I would use normally, discarding concepts I would never use and features I would never really be interested in during my life as a game developer. I looked deeply into the implementations I was interested in and tried to see if I could improve on them performance wise.
What I found was that most implementations were quite well developed and were quite efficient - at least as much as they could be. There was very little room for direct optimization, which wasn’t even worth the effort. For the optimizations that were possible...typically they'd be related to the deployment/use and as such would also be necessary if you were to take the ‘rolling your own’ containers option anyway or the optimizations were possible only by removing features to allow corner cutting.
The latter were more interesting to me because clear performance (and memory) wins were easy and possible via this route. This should surprise no one though…because the outcome of removing features is a more specialized case and as we all know, specialized cases will generally be more performant than generic ones. I actually don’t find too much fault with STL for being generic and flexible either – that’s kind of the point of it. I should also add that programming IMHO is often about making trade off decisions and sometimes generic/flexible is just a better choice anyway.
Unfortunately, this result did give me the excuse I needed to continue using and maintaining my own containers because I don’t need to give clock cycles away anyway. However, before the haters applaud I will also add that while such exercises do provide measurable gains at the instruction level please bear in mind that the % of time your program counter is iterating over such instructions is very minimal. The gains you’ll see to your frame rate by such techniques are often not going to be as noticeable.
I should also add that while I do use my own containers, that wasn’t an excuse for me to throw STL containers away. I still use them actually, particularly in code that I share with others or in code that needs to be more flexible.
A TL/DR version, which is also roughly the takeaway from my own research
- In rolling your own it’s easy to make performance gains, but you’re not really optimizing STL – you’re removing features and making something else. Apples and oranges don’t really compare.
- I did make some memory gains too, as I briefly hint at above.
- The more features you add, the more the gap will close on any gains you made - the more pointless having your own will be.
- If you can live without those features the performance gains are worth it at the instruction level.
- The same performance gains have limited worth overall, largely due the time your program counter is in these so called problem areas. Or…there should be bigger fish to fry when you look at your performance profile.
- It is possibly worth using your own to gain maximum performance for your run time regardless (as I say above…why thrown cycles away).
- Rolling your own is an interesting exercise, particularly if you do look at the existing implementations. You’ll learn a lot about them and I think make wiser decisions for having that knowledge.
- Rolling your own with the intention of supporting all the same features is pointless. Things will exist in your version for the same reason they exist in vendor versions, which have already been optimized as they are. You really will be reinventing the wheel here and you’ll do that via creating a less optimal wheel at least in the first instance.
- Where you don’t need performance, the only possible need to use your own might be for reasons of consistency and not using two different types of containers.
- It’s my opinion that your tools/pipeline and generally your higher level code are better off using STL/standard C++ library containers though. Why?…
- They are more flexible and this sort of code generally needs to have that benefit
- The same code will be more maintainable due to using something more flexible
- Because they are standard and everyone should know them. Not everyone will be aware of the nuances of your own version, even if it’s a version shared amongst several people.
- The advantage of the alternative has no place here.