Switch from Microsofts STL to STLport

Question

I\'m using quite much STL in performance critical C++ code under windows. One possible \"cheap\" way to get some extra performance would be to change to a faster STL library.

Answer 1

I've done the exact opposite a year ago and here is why:

• StlPort is updated very rarely (as far as I know only one developer is working on it, you can take a look at their commit history)
• Problems building it whenever you switch to new Visual Studio release. You wait for the new make file or you create it yourself but sometimes you can't build it because of some configuration option that you're using. Then you wait for them to make it build.
• When you submit a bug report you wait forever, so basically no support (maybe if you pay). You usually end up fixing it yourself, if you know how.
• STL in Visual Studio has checked iterators and debug iterator support that is much better than the one in StlPort. This is where most of the slowdown comes from especially in debug. Checked iterators are enabled in both debug and release and this is not something everybody knows (you have to disable them yourself).
• STL in Visual Studio 2008 SP1 comes with TR1 and you don't have this in StlPort
• STL in Visual Studio 2010 uses rvalue references from C++0x and this is where you get a real performance benefit.

Answer 2

I haven't compared the performance of STLPort to MSCVC but I'd be surprised if there were a significant difference. (In release mode of course - debug builds are likely to be quite different.) Unfortunately the link you provided - and any other comparison I've seen - is too light on details to be useful.

Before even considering changing standard library providers I recommend you heavily profile your code to determine where the bottlenecks are. This is standard advice; always profile before attempting any performance improvements!

Even if profiling does reveal performance issues in standard library containers or algorithms I'd suggest you first analyse how you're using them. Algorithmic improvements and appropriate container selection, especially considering Big-O costs, are far more likely to bring greater returns in performance.

Answer 3

If you use the STLPort you will enter a world where every STL-based third party library you use will have to be recompiled with STLPort as well to avoid problems...

STLPort does have a different memory strategy, but if this is your bottleneck then your performance gain path is changing the allocator (switching to Hoard for example), not changing the STL.

Answer 4

Before making the switch, be sure to test the MS (in fact, Dinkumware) library with checked iterators turned off. For some weird reason, they are turned on by default even in release builds and that makes a big difference when it comes to performance.

Answer 5

In a project i worked on that makes quite heavy use of stl, switching to STLport resulted in getting things done in half the time it took with Microsoft's STL implementation. It's no proof, but it's a good sign of performance, i guess. I believe it's partly due to STLport's advanced memory management system.

I do remember getting some warnings when making this change, but nothing that couldn't be worked around fast. As a drawback, I'd add that debugging with STLport is less easy with Visual Studio's debugger than with Microsoft's STL (Update : it seems there is a way to explain to the debugger how to handle STLport containers, thanks Jalf !).

The latest version goes back to October 2008 so there are still people working on it. See here for downloading it.

Answer 6

We have done the opposite task recently. Our application is a cross-platform C++ server program and it is built on Windows with VS 2008 (x86) and on HP-UX ia64 and Linux with gcc 4.3 . On every platform we used the STLport 5.1.7 as an STL library and Boost 1.38.

In order to compare performance some time ago we also built our application without STLport and after that we measured performance.

After that on Windows the performance became slightly better. So we chose to stop using the STLport with VS 2008 and to use the default VS 2008 STL library.

On HP-UX ia64 there was 20% decrease in performance. Caliper (the HP-UX profiler) showed that string assignments took more time. And inside of string assignment in the default gcc STL library there were calls to pthread_mutex_unock. As far as I know pthread_mutex_lock/pthread_mutex_unlock are used since the default gcc's STL library uses COW-strings. In our application we do lots of string assignments and as a result of the COW strings we get worse performance. So we still use STLPort on HP-UX with gcc.