469,575 Members | 1,658 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,575 developers. It's quick & easy.

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
Jul 19 '05 #1
7 7212

"Thomas" <td*****@att.com> wrote in message news:bl**********@kcweb01.netnews.att.com...
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...
Jul 19 '05 #2
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" <ro*@sensor.com> wrote in message
news:3f*********************@news.newshosting.com. ..

"Thomas" <td*****@att.com> wrote in message

news:bl**********@kcweb01.netnews.att.com...
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...

Jul 19 '05 #3
Thomas wrote:
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
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

Jul 19 '05 #4
Thomas wrote:
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 --

Jul 19 '05 #5

"John Tsiombikas (Nuclear / the Lab)" <nu*****@siggraph.org> wrote in
message news:1064611010.658265@athprx02...
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.


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.)
Jul 19 '05 #6

"Thomas" <td*****@erols.com> wrote in message
news:bl**********@bob.news.rcn.net...
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
Jul 19 '05 #7
In article <bl**********@bob.news.rcn.net>, td*****@erols.com says...
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).

--
Later,
Jerry.

The universe is a figment of its own imagination.
Jul 19 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

10 posts views Thread by Oliver S. | last post: by
23 posts views Thread by YinTat | last post: by
4 posts views Thread by Carl Youngblood | last post: by
27 posts views Thread by djake | last post: by
13 posts views Thread by Rob Meade | last post: by
7 posts views Thread by craigkenisston | last post: by
2 posts views Thread by Tony Winslow | last post: by
4 posts views Thread by guiromero | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.