Re: simple code performance question
On 5 nov, 14:20, Ioannis Gyftos <ioannis.gyf...@gmail.com> wrote:
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?
I ran the same test as you did and I can confirm your result. I didn't
bother without optimization in any case.
However, since std::string::append did strike me as a bit unorthodox
(appending is the first you thought of?), i took the liberty to run
Yes, because I wanted a huge string, not only to mimic assignment.
Without delving in obscure std::string methods, how do you create a
huge std::string without appending content to it?
the same tests with:
str = "supercalifragili...";
instead of appending. With optimization -O3 on gcc 4.2.1, program 1
ran at 26.5 sec. Program 2 ran at 28.0 sec. If I remove the
"str.clear();" line in Program 2, I get 26.4sec.
(Yeah slow PC)
Can you explain me that? :)
Well, of course clearing the string was not necessary in your case.
The explanation in my example was memory management, as you can easily
deduce from the 3.7 seconds of system time required for Program 1 to
run to completion, compared to 0.3 for Program 2. Under Linux, the
time command gives you this info. Now, in your case both versions had
the same execution time, so there should be no preferred way, and I
will stick to mine. Also, being everything the same, what do you want
me to explain?
Hint hint: Program 2 returns a reference (to an increasingly large
std::string), so the two programs are not fair imo.
Neither the program returns any reference nor the void myFunction
does, I don't see what you mean.
On another similar note. Which one would you _prefer_?
for (std::list<...>::iterator i = myList.begin();
i != myList.end(); ++i)
{}
versus
std::list<...>::iterator i = myList.begin();
std::list<...>::iterator j = myList.end();
for ( ; i != j ; ++i)
{}
The former. As Bazarov has already noticed, both should be equivalent
unless the compiler does any calculation to arrive at myList.end(),
which is unlikely.
On the other hand, it could be interesting to avoid things like:
for ( std::vector<...>::size_type i( 0 ); i < myVector.size(); ++i );
because the size() member is likely to end up being inline expanded to
myVector.end() - myVector.begin(), so saving it in a variable could be
a good idea in performance sensitive applications. In such cases I do
write:
std::vector<...>:size_type size( myVector.size() );
for ( std::vector<...>::size_type i( 0 ); i < size; ++i );
Notice that the second _cannot_ be much slower than the former (it
will be at most one integer type creation slower), but can potentially
avoid thousands of recalculations. When you come into a loop that only
executes one subtraction within each iteration (and it does happen a
lot to me), the former will be doubling the execution time, unless if
optimized by the compiler (which would result in code similar to
mine), but such optimization may not be an easy task for it.
Of course using iterators here would be much more elegant, but some
algorithms are best implemented with indexes. It is much easier to
provide indexes when working with matrices representing images than to
work with iterators. By the way, why there is no std::matrix? It makes
me unhappy.
Perhaps I am neurotic about performance, but I do need to be. That's
why I chose C++ over Python. If one is to be writing sloppy C++ code,
why not move to Python?
Elias Salom=E3o Helou Neto