Re: simple code performance question
This has nothing to with reference counting. The problem with
assignment is that the string assigned to already has a value. What
are we going to do with that? How long does that take?
Now I see what you meant!
Release memory, not longer than destroying the object every iteration
of the loop, right?
(and I'm not trying to win a litterature prize)
But you are trying to be understood.
: If so, why would not it hold as well for copying? Think about it!
: Copying may be done on write, allright, but why could not
: assignement do exactly the same, i.e. copy on write with reference
: counting for the data? If it is done so, when a temporary argument
: is passed for either the copy constructor or the assignement
: operator, actual copying of the data would never take place.
:
::: But the real point here is that you were using something like str
::: = someFunction() instead of someFunction( str ). Do you see?
::
:: No, I don't! :-)
::
:: We have a perfectly good and idiomatic piece of code in section 2.
:: It is simple, easy to read, and actualy runs faster. What more
:: could we ask??
:
: I ask to compare it to what it should be compared to, not to an
: oversimplified version. I mean that str( someFunction() ) is not to
: be benchmarked against str = someFunction() when optimization is
: turned on because, in the former, temporaries are rather easy to be
: eliminated, while in the second no!
I don't get this one.
What can I say, then? Try to squeeze your brain.
:
:: In section 1, the programmer tries some kind of premature
:: optimzation which just complicates the code. That he also gets
:: worse run-time performance, is well deserved!
:
: Is it well deserved to receive a performance penalty solely for
: deviating from an idiom? Now, an affirmative answer to this would be
: dumb!
Ok. :-)
Trying to outsmart the compiler, and getting slower code is well
deserved IMO.
When did I try to outsmart the compiler?
::: Also, in normal cases, optimizations may not be as simple as they
::: are with std::string, which is under the compiler control (in
::: fact, the implementation of std::string should be near optimal
::: without any compiler optimization anyway). Within user-defined
::: classes, copy construction may execute startup code that will be
::: cleaned up upon destruction, which would not happen with
::: assignement operations, so the construction/destruction cycle
::: within a loop should best be avoided in most cases when it is not
::: needed, unless assignement is specially poorly implemented. In
::: such cases, however, it would be better to reimplement the
::: assignement properly. That is the reason my advice is to place
::: constructors outside the loop, though exceptions to the rule may
::: exist (yours doesn't seem to be one) AND to refrain from
::: returning large objects by value, wich would avoid the creation
::: of temporaries.
::
:: The fact is that std::string has no overhead in its copy
:: constructor, all it does is store a copy of the other string.
:
: I cannot figure out what you are meaning. Should not every copy-
: constructed object store a copy of the copied object? I guess you
: wanted to mean that they share data (copy on write).
No, I mean that constructing a string object from scratch can be
faster than destroying the old value, and then copying the new one.
Well, again you forget that your idiom has an implied destruction of
the object at every loop iteration, resulting in the need to deal with
exactly the same problem! How could that be different?
I will give you an example. Take the following two simple programs:
//Program 1:
#include <string>
std::string myFunction()
{
std::string str;
for ( unsigned i( 0 ); i < 1000; ++i )
str.append( "supercalifragilisomethingidonotremebmberandd"
"donotwantotsearchintheinternet" );
return( str );
}
int main()
{
for( unsigned i( 0 ); i < 100000; ++i )
std::string str( myFunction() );
return( 0 );
}
//Program 2:
#include <string>
void myFunction( std::string& str )
{
str.clear();
for ( unsigned i( 0 ); i < 1000; ++i )
str.append( "supercalifragilisomethingidonotremebmberandd"
"donotwantotsearchintheinternet" );
}
int main()
{
std::string str;
for( unsigned i( 0 ); i < 100000; ++i )
myFunction( str );
return( 0 );
}
According to you, Program 1 should run faster, right? But it is just
the opposite. Compiling both with no optimization (the default) using
gcc 4.1.2 20070502 Program 1 takes around 21 seconds to run against
around 15 seconds for Program 2. Now, let us turn optimization to its
higher level and see what happens. With the -O3 flag used when
compiling, Program 1's execution time falls to around 19 seconds,
while Program 2 goes down to amazing 12 seconds! Can you explain me
that?
It's time for another listing:
//Program 3:
#include <string>
std::string myFunction()
{
std::string str;
for ( unsigned i( 0 ); i < 1000; ++i )
str.append( "supercalifragilisomethingidonotremebmberandd"
"donotwantotsearchintheinternet" );
return( str );
}
int main()
{
std::string str;
for( unsigned i( 0 ); i < 100000; ++i )
str = myFunction();
return( 0 );
}
Program 3 takes little more than 17 seconds to run without
optimization turned on, explain it to me, please. When optimized, it
will take around 15 seconds to run.
Even though it is a contrived example, it shows who knows what is
talking about here. And I, for sure, did not have to look for some odd
example, it was the first one I tried.
From now on, refrain from making statements without the required
knowledge, all right? And always remember to try things out before
blindly believing in what people say to you (start by trying the
listings here).
Elias Salom=E3o Helou Neto