What is the STL implementation with the lowest memory footprint?

Question

I am working on a very large scale computing library that is using STL heavily. The library is being built using MSVC2003 and it is using its STL implementation. I am looking for an alternative STL implementation that would help the library lower its memory requirements and increase its performance.

It is not possible to switch to a newer version of MSVC for the moment.

I would like some feedback on real world usage not based on benchmarks if possible.

EDIT: To make it a little clearer, for example some STL implementation (like STLSoft) are proposing specific optimizations for string concatenation; these might sounds small in impact but they can lead to large improvements. STLPort is another good example where they clearly state their goal: having the fastest STL implementation around, there is the stdlib++, etc ... all of these can be good candidates but I have no time to test them all, i require some community help on that.

Answer 1

STLPort. Havent measured memory usage differences, but it's definitelly quicker (yes, real world usage).

Answer 2

I question your basic premise, that you can not switch to a newer version of MSVC.

I don't think you're going to get lower memory and increased performance "for free" by downloading a new STL. Or at least, if you did, you would probably have to do as many code fixes as if you were to just update to the latest MSVC.

Long term, there's no question you want to update... Do it now, and you might get lucky and get some of that memory and performance for free.

The only thing I can think to suggest to you along the lines of what you say you're looking for would be to try the Intel compiler, which I've had both good (performance!) and bad (quirky, sometimes!) experience with.

Other than that, find your own memory and performance problems, and write custom containers and algorithms. STL is awesome, but it's not a panacea for fixing all problems in all cases. Domain knowledge is your best ally.

Answer 3

Most STL implementations, including the one of MSVC2003, are well implemented generic libraries. So you won't see a significant performance improvment from one implementation to the other.

However, sometimes you can write algorithm (or container) that are faster than the STL for you because you know something about your data that the STL writer did not new (since they were writing generic containers and algorithm).

In conclusion, if you want to improve your applications performances, you better try to create specialised containers that fit you data specially than looking for a more performant STL.

Answer 4

If performance is so critical to your application, and STL is interwoven into it, is it possible to find an open-source implementation (such as STL-Port, as mentioned) and fork it for yourself, making performance improvements as needed?

On the one hand, I can see this becoming a slippery slope where you make non-standard modifications to your fork of the STL library, thus creating problems. However, importance of performance to your application might outweigh the risk of this occurring.

Answer 5

Have you considered writing your own memory allocator? You don't always need to switch the entire STL if you just don't like the memory allocation strategy. All containers accept a replacement allocator.

Answer 6

Have you profiled your code and considered small tweaks to those areas that are the problem? I would think it would be much less painful than what you're considering.

Answer 7

Most of it depends on which container you are talking about, and how you are using it. vector usually has the smallest footprint, except at the moment you add an element that is beyond the current vector capacity. At that moment it it will allocate something like 1.5 x the current vectors capacity, move the elements (or in the worst case make a new copy which also allocates memory) and when that is done, delete the old vectors internals, If you know how many elements it is going to hold up front, vector with a use of reserve is your best bet.

The second smallest is list. It has the advantage that its not going to make a temporary copy of itself. After that set is your best bet is probably set. Some implementation have slist now, which is smaller. In these cases tt is pretty easy to make an allocator that packs the memory in pages. Stay away from memory hogs like unordered_*

On MSVC be sure to #define _SECURE_SCL=0 This takes out a lot of overhead used for secure programming checks (like buffer overruns, etc)

By far the most memory efficient containers are boost/intrusive These have extremely small footprints since they use the memory of the thing being contained. So instread of going to the heap for a small chunk of memory for a linked list or rb tree node, the node pointers are part of the object itself. Then the "container" is just one raw set of a few pointer to make a root node. I've used it quite a few times to get rid of footprint and allocation overhead.