Re: Why is VC++ STL so slow?
"Earl Purple" <earlpurple@gmail.com> wrote in message
news:1159887354.091083.309270@m7g2000cwm.googlegroups.com...
P.J. Plauger wrote:
Well yes, but string and vector deal with a single block of storage
at any given time. A pooled allocator shares multiple nodes across
all maps of a given type, which introduces synchronization issues in
a multithreaded system. And when I say they fail to release storage,
I mean even at program termination.
Isn't there an "in-between" of having a pooled allocator per collection
rather than per type. Then it would be as thread-safe as it needs to
be.
Right, and then it would use more storage on average, because each
container object would hog the nodes needed at its maximum size
and not share the excess with other containers. There's lots of
tradeoffs in storage allocation -- the hard part is guessing a
default that works well enough for most cases.
By the way, if one has a sorted vector and is then going to convert
this to a set, it is quicker to start from the middle element and move
outward in each direction thus keeping the tree balanced?
Maybe, if you alternated the inserts from either side, and used
insert with hint (and had a decent implementation of insert with
hint). Trying to optimize by reflecting the internals of a data
structure in your code is dangerous, however. You often guess
wrong about where the time savings are to be had, and you're a
sucker for changes in the internals of the data structure.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]