This article is an attempt to do a performance comparison of the STL/CLR sequential containers with corresponding generic collections in the BCL. To my total surprise, the STL/CLR containers fell way behind the BCL classes. Talk about misleading expectations. 😦
Nice article Nish,
I’m suprise too about this performances.
I thought stl/clr was designed only for using native object in containers. My guess is that perfomance wasn’t the first purpose.
Nish,
Great meeting you yesterday at the MVP Summit!
Cheers
Al
I just copied and ran your code. I used just a simple command line and just the insert and remove test.
Using 10000000 iterations
With Debug build, I got
List:306
Vector:1297
Using Release
List:254
Vector:424
It seems that the performance is still slower, but not nearly as bad once the optimizer gets a chance at it
With Release
Here is some more data from running the iterator and sort tests
For release I chose the favor fast code optimization and inline any suitable
Debug
InsertRemove (List vs Vector vs StdVector)
244
1188
3648
Iterate (List vs Vector vs StdVector)
217
1338
2629
Sort (List vs Vector vs StdVector)
927
2102
10194
Press any key to continue . . .
And Release version
InsertRemove (List vs Vector vs StdVector)
288
414
387
Iterate (List vs Vector vs StdVector)
247
463
298
Sort (List vs Vector vs StdVector)
939
717
308
Press any key to continue . . .
Some early conclusions
1) The STL code is absolutely dependent on the optimizer
2)The std::stl with optimizer hangs in with the BCL for most tests and stomps it in the sort test.
3) The cliext::stl is slower than the std version but manages to also win handily in sorting
Nishant, do you know if you had optimizations enabled
Nish, This is a very good exposé. Were you in debug mode suffering from MDA problems? (See Jeff’s comments and link on your page at http://blog.voidnish.com/?p=94. I’ve seen no mention of that problem being fixed.) If not, I’m as surprised as you!! This is a very strong indictment against the compiler. It must be generating code that thunks and copies at every turn, none of which is necessary. If no fix for the compiler is on the horizon, many of us in industry will have to reevaluate how, where, and (in some cases) even if managed C++ can play a role in our competitive markets. Thanks much for this heads up.