I know of absolutely no reason why list, set, and map should have slowed
down, certainly not to the extent you're describing. For a time, Microsoft
was supplying a V6 version of <xtree> (for set and map) that went overboard
on locking and was probably *really* slow, but the replacement <xtree>
from our web site avoids those problems. We've also fixed some subtle
bugs in <xtree> since V6, so sets and maps are way more robust now;
but those fixes shouldn't cause any performance hit.
I have reason to believe that Microsoft is taking this report seriously, and
that better folks than I are studying the matter. If they locate any
in the STL code proper, we'll of course supply a rapid fix. But meanwhile,
I defer to Microsoft to report on any problems and fixes as they find them.