VC STL - ostringstream "<<" performance issue

Author

ostringstream "<<" performance issue

vijay

2005-08-09, 4:05 am

Platform : VC 7.1.3088

Hi,
I am inserting data of length 100 in ostringstream using << operator which
is taking lots of time. Is there any way to reduce time.

Regards
vijay

Ulrich Eckhardt

2005-08-09, 4:05 am

vijay wrote:
> I am inserting data of length 100 in ostringstream using << operator which
> is taking lots of time. Is there any way to reduce time.

Yes, lots. If you look at the IOStreams architecture, you will see that each
field triggers possibly several lookups in a map of facets that are
responsible for formatting the value. There are several calls to virtual
functions involved, as well as several try-catch-clauses, all of which
might slow things down.

In cases where you do not need locale-sensitive formatting, you might be
better off using these facets directly or even completely different ways to
format things. If you know in advance the number of characters your data
will take, that is a further optimisation opportunity. Switching to a
different implementation of standardlibrary might help, too - rumours have
it that STLport is in some corner cases less compliant but offers better
performance for IOStreams.

Uli

P.J. Plauger

2005-08-09, 9:05 am

"Ulrich Eckhardt" <eckhardt@satorlaser.com> wrote in message
news:vcvls2-oov.ln1@

oc.satorlaser-intern.com...

> vijay wrote:
>
> Yes, lots.

Maybe. It depends on where that time is being spent, and whether
your concept of "lots" is meaningful and accurate.

> If you look at the IOStreams architecture, you will see that each
> field triggers possibly several lookups in a map of facets that are
> responsible for formatting the value. There are several calls to virtual
> functions involved, as well as several try-catch-clauses, all of which
> might slow things down.

Agreed, with emphasis on the "might".

> In cases where you do not need locale-sensitive formatting, you might be
> better off using these facets directly or even completely different ways
> to
> format things. If you know in advance the number of characters your data
> will take, that is a further optimisation opportunity.

Not sure what that is. You can't preallocate storage for an ostringstream
(without some dubious trickery), and that probably wouldn't pay off for
a mere 100 chars anyway.

> Switching to a
> different implementation of standardlibrary might help, too - rumours have
> it that STLport is in some corner cases less compliant but offers better
> performance for IOStreams.

Facts have it that STLport fails 20 per cent of our validation tests.
See:

http://www.dinkumware.com/conform_cpp.html

And those aren't all "corner cases". Quite a number of failures
are simply bugs.

That figure hasn't improved in the last several years, either. Note
also that STLport hasn't been formally supported for quite some
time. A couple of volunteers have been trying, but with mixed
success. Browse the forum:

http://www.stlport.org/cgi-bin/forum/dcboard.cgi

before you commit to installing their latest release candidate,
RC4. BTW, if you try to report problems on any of the versions
available on their download page:

http://www.stlport.org/download.html

the volunteers will tell you to try RC4 because they don't
support the formal release, or any earlier betas.

A safer path is to measure where your program is spending its
time, then ask in this forum whether faster methods exist
that might address any performance problems you find.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

Ulrich Eckhardt

2005-08-09, 9:05 am

P.J. Plauger wrote:
> "Ulrich Eckhardt" <eckhardt@satorlaser.com> wrote in message
> news:vcvls2-oov.ln1@

oc.satorlaser-intern.com...
>
> Facts have it that STLport fails 20 per cent of our validation tests.
> See:
>
> http://www.dinkumware.com/conform_cpp.html
>
> And those aren't all "corner cases". Quite a number of failures
> are simply bugs.

I completely believe you, although I haven't seen the exact failures - I
also believe that we had this discussion already.

> That figure hasn't improved in the last several years, either.

One question here, did you do a similar comparison recently? The tests seem
quite old. And did you only compare with official releases (i.e. 4.6.2 at
latest) or did you also try one of the 5.0 release candidates?

> Note
> also that STLport hasn't been formally supported for quite some
> time. A couple of volunteers have been trying, but with mixed
> success. Browse the forum:
>
> http://www.stlport.org/cgi-bin/forum/dcboard.cgi

I'm perfectly aware of this, as I'm one of these volunteers (in fact I'm
getting paid for it, though not by STLport, so one might consider me a
non-volunteer).

Works For Me(tm) under VC6 and eVC4, the stdlibrary that comes with VC7.1 (I
believe from Dinkumware) is much better that the one that comes with those
other two, which is why there we don't need to use STLport.

Uli

P.J. Plauger

2005-08-09, 9:05 am

"Ulrich Eckhardt" <eckhardt@satorlaser.com> wrote in message
news:8hmms2-hl1.ln1@

oc.satorlaser-intern.com...

> P.J. Plauger wrote:
>
> I completely believe you, although I haven't seen the exact failures - I
> also believe that we had this discussion already.

Yes, we did. That's why I objected to the characterization that
"STLport is in some corner cases less compliant," which I believe
is inaccurate.

>
> One question here, did you do a similar comparison recently? The tests
> seem
> quite old. And did you only compare with official releases (i.e. 4.6.2 at
> latest) or did you also try one of the 5.0 release candidates?

We try *all* the release candidates. If we can get them to build on
one or more platforms -- and we can't always -- we run our tests
against them. (The evidence is that we test all the open source
packages more thoroughly than their developers do.) That's why I can
say with confidence that STLport conformance hasn't improved in the
last several years.

>
> I'm perfectly aware of this, as I'm one of these volunteers (in fact I'm
> getting paid for it, though not by STLport, so one might consider me a
> non-volunteer).
>
> Works For Me(tm) under VC6 and eVC4,

And I agree that's reason enough to use a package.

> the stdlibrary that comes with VC7.1
> (I
> believe from Dinkumware) is much better that the one that comes with those
> other two, which is why there we don't need to use STLport.

Yep.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

Stephen Howe

2005-08-09, 5:07 pm

> Not sure what that is. You can't preallocate storage for an ostringstream

An underspecification in the standard.
You can reserve space with vector and string, specify a buffer with fstream,
why not stringstream family?

Stephen Howe

Sponsored Links