stl string class performance

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

re: stl string class performance

"Thomas" <tdineen@att.com> wrote in message news:bl1obc$2ts13@kcweb01.netnews.att.com...[color=blue]
> 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.[/color]

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...

re: stl string class performance

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



"Ron Natalie" <ron@sensor.com> wrote in message
news:3f746c4a$0$204$9a6e19ea@news.newshosting.com. ..[color=blue]
>
> "Thomas" <tdineen@att.com> wrote in message[/color]
news:bl1obc$2ts13@kcweb01.netnews.att.com...[color=blue][color=green]
> > Does anyone know if the stl string class implements some sort of pooling[/color][/color]
or[color=blue][color=green]
> > chunking of memory for performance optimization? I know that the Lucent[/color][/color]
SCL[color=blue][color=green]
> > has this built in, but not sure if the same is true of STL. The platform[/color][/color]
is[color=blue][color=green]
> > Solaris 2.8.[/color]
>
> 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...
>
>[/color]

re: stl string class performance

Thomas wrote:[color=blue]
> Ron,
> Thanks for the feedback.[/color]
<snip>

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

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

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

re: stl string class performance

Thomas wrote:[color=blue]
> 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.[/color]

I would expect most implementations to be quite optimized, making OS
system calls for every allocation would be quite stupid in most systems.
[color=blue]
> 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.[/color]

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.
[color=blue]
> I am using the Solaris version that comes with 6.2 on Solaris 8.
> Thanks again,
> Thomas[/color]

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 --

re: stl string class performance

"John Tsiombikas (Nuclear / the Lab)" <nuclear@siggraph.org> wrote in
message news:1064611010.658265@athprx02...[color=blue][color=green]
> > My reason for asking is that if SCL has this implementation in place[/color][/color]
and[color=blue][color=green]
> > 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[/color][/color]
benefit[color=blue][color=green]
> > significantly from that optimization.[/color]
>
> 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.[/color]

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.)

re: stl string class performance

"Thomas" <tdineen@erols.com> wrote in message
news:bl248t$nj9$1@bob.news.rcn.net...[color=blue]
> Ron,
> Thanks for the feedback. What I was looking for was more along the lines[/color]
of[color=blue]
> 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.[/color]

See the 'allocator' template argument for std::string.
Also don't forget member functions 'reserve()' and 'resize()'.
[color=blue]
> 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.[/color]

You can provide your own allocator via a template argument.
[color=blue]
>The
> application I support uses strings and lists extensively and would benefit
> significantly from that optimization.[/color]

All the containers can have allocator template arguments.

-Mike

re: stl string class performance

In article <bl248t$nj9$1@bob.news.rcn.net>, tdineen@erols.com says...[color=blue]
> 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.[/color]

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).

--
Later,
Jerry.

The universe is a figment of its own imagination.