stl string class performance

[Thomas]

Does anyone know if the stl string class implements some sort of pooling or
chunking of memory for performance optimization? I know that the Lucent SCL
has this built in, but not sure if the same is true of STL. The platform is
Solaris 2.8.

Thanks,

Thomas

 

[Ron Natalie]

Does anyone know if the stl string class implements some sort of pooling or
chunking of memory for performance optimization? I know that the Lucent SCL
has this built in, but not sure if the same is true of STL. The platform is
Solaris 2.8.

You haven't indicated what implementation you are talking about.

#include <string>
#include <iostream>
using namespace std;

int main() {
string s;
while(true) {
s += " ";
cout << s.size() << " " << s.capacity() << "\n";
}
}

For the G++ version I tried, size and capacity track each other up to 116
charaacters, then the capacity starts jumping 227, 355, 483, 611, 739...

 

[Thomas]

Ron,
Thanks for the feedback. What I was looking for was more along the lines of
a separate pool object, i.e. memory manager, that would handle the memory
allocation for all the objects. Rather than having to ask the o.s for
additional memory, it (string, list, etc) would get it from the pool
object. If the pool object didn't have enough, it would then have to
reallocate. Once the string, list, etc were done with the memory, it would
get returned to the pool object.
My reason for asking is that if SCL has this implementation in place and
the vendor supplying the STL does not, then it is very likely that I can
expect considerable performance degradation when migrating to STL. The
application I support uses strings and lists extensively and would benefit
significantly from that optimization.
I am using the Solaris version that comes with 6.2 on Solaris 8.
Thanks again,
Thomas

 

[Kevin Goodsell]

Ron,
Thanks for the feedback.

<snip>

Please don't top-post. Read section 5 of the FAQ for posting guidelines.

http://www.parashift.com/c++-faq-lite/

-Kevin

 

[John Tsiombikas (Nuclear / the Lab)]

Ron,
Thanks for the feedback. What I was looking for was more along the lines of
a separate pool object, i.e. memory manager, that would handle the memory
allocation for all the objects. Rather than having to ask the o.s for
additional memory, it (string, list, etc) would get it from the pool
object. If the pool object didn't have enough, it would then have to
reallocate. Once the string, list, etc were done with the memory, it would
get returned to the pool object.

I would expect most implementations to be quite optimized, making OS
system calls for every allocation would be quite stupid in most systems.

My reason for asking is that if SCL has this implementation in place and
the vendor supplying the STL does not, then it is very likely that I can
expect considerable performance degradation when migrating to STL. The
application I support uses strings and lists extensively and would benefit
significantly from that optimization.

There isn't such thing as "the STL vendor", The C++ Standard Library is
a specification, there are many different implementations, for instance
every compiler usually has its own Standard Library implementation.

I am using the Solaris version that comes with 6.2 on Solaris 8.
Thanks again,
Thomas

then go to a solaris-specific newsgroup or a newsgroup dedicated to the
compiler you use on solaris and ask them about their implementation of
the Standard Library.

-- Nuclear / the Lab --

 

[jeffc]

There isn't such thing as "the STL vendor", The C++ Standard Library is
a specification, there are many different implementations, for instance
every compiler usually has its own Standard Library implementation.

He didn't say "the STL vendor". He said "the vendor supplying the STL".
This implies the vendor supplying the STL implementation (see the first half
of the sentence.)

 

[Mike Wahler]

Ron,
Thanks for the feedback. What I was looking for was more along the lines of
a separate pool object, i.e. memory manager, that would handle the memory
allocation for all the objects.
Rather than having to ask the o.s for
additional memory, it (string, list, etc) would get it from the pool
object. If the pool object didn't have enough, it would then have to
reallocate. Once the string, list, etc were done with the memory, it would
get returned to the pool object.

See the 'allocator' template argument for std::string.
Also don't forget member functions 'reserve()' and 'resize()'.

My reason for asking is that if SCL has this implementation in place and
the vendor supplying the STL does not, then it is very likely that I can
expect considerable performance degradation when migrating to STL.

You can provide your own allocator via a template argument.

The
application I support uses strings and lists extensively and would benefit
significantly from that optimization.

All the containers can have allocator template arguments.

-Mike

 

[Jerry Coffin]

Ron,
Thanks for the feedback. What I was looking for was more along the lines of
a separate pool object, i.e. memory manager, that would handle the memory
allocation for all the objects. Rather than having to ask the o.s for
additional memory, it (string, list, etc) would get it from the pool
object. If the pool object didn't have enough, it would then have to
reallocate. Once the string, list, etc were done with the memory, it would
get returned to the pool object.

There's nothing in the standard to mandate behavior like this, but it's
a fairly accurate description of how things _usually_ work. The
containers in the standard library allow the user to specify an
allocator object that will be used to allocate memory for the
collection. The default allocator will use new and delete to allocate
and free memory.

Since it's not observable behavior (in the way "observable" is meant by
the standard) there's no requirement that new and delete allocate large
chunks of memory from the OS, and sub-allocate out of those. In fact, I
know of one version of one compiler that _did_ use OS calls every time
you allocated or freed memory -- that's a rare (and long-since obsolete)
exception though. Simple market pressure prevents it from becoming
common; nearly everybody has at least a few competitors, and speeding up
the default new and delete will give a competitor a substantial
improvement in both benchmark scores AND in real speed, so most try to
make it at least pretty good (though if it becomes an issue, there are
after-market memory managers that might be worth looking into).