efficient assignment ???

[Programmer]

Is this:

int x;
for (int count=0; count<200; count++)
{
x = someFunc();
anotherFunc(x);
}


more efficient than this:

for (int count=0; count<200; count++)
{
int x = someFunc();
anotherFunc(x);
}

can someone also explain why?
thanks.

 

[Karl Heinz Buchegger]

Is this:

int x;
for (int count=0; count<200; count++)
{
x = someFunc();
anotherFunc(x);
}

more efficient than this:

for (int count=0; count<200; count++)
{
int x = someFunc();
anotherFunc(x);
}

can someone also explain why?
thanks.

Try it with your compiler. You can use the timing
functions clock() to figure this one out

eg.

#include <cstdio>
#include <cstdlib>
#include <ctime>

using namespace std;

int main()
{
clock_t start = clock();

// your code goes here

clock_t finish = clock();

double duration = (double)(finish - start) / CLOCKS_PER_SEC;
printf( "%2.f seconds\n", duration );
}

But make sure, that the duration is long enough. Usually just reapeating
what you need to time a few million times makes it long enough, such
that the resotion of clock() doesn't matter any more (In other words:
make sure your program runs at least a few seconds).

 

[Bart Blommerde]

Is this:

int x;
for (int count=0; count<200; count++)
{
x = someFunc();
anotherFunc(x);
}


more efficient than this:

for (int count=0; count<200; count++)
{
int x = someFunc();
anotherFunc(x);
}

The second format will be optimized by your compiler to the first one.
I'd say the second runs as fast as the first, since declarations don't
need any processing.



regards,
Bart

 

[lilburne]

Is this:

int x;
for (int count=0; count<200; count++)
{
x = someFunc();
anotherFunc(x);
}


more efficient than this:

for (int count=0; count<200; count++)
{
int x = someFunc();
anotherFunc(x);
}

can someone also explain why?
thanks.

You'll probably find that for PODs the compiler will optimize example 2
to be similar to example 1. This won't be the same for non POD
variables. I've seen as much as 17% slowdown for code that looked like:

for (int count=0; count<200; count++)
{
myClass a = someFunc();
anotherFunc(a);
}

run the profiler.

 

[Phlip]

Is this:

int x;
for (int count=0; count<200; count++)
{
x = someFunc();
anotherFunc(x);
}


more efficient than this:

for (int count=0; count<200; count++)
{
int x = someFunc();
anotherFunc(x);
}

can someone also explain why?

The second is more efficient in terms of programming time. The most
important resource to optimize is programmer time. Do not worry about which
statements are more efficient, worry about how likely they are to catch a
bug. The first version is more risky because you might find yourself using x
outside that loop, and not notice that inside the loop x gets changed.

Always give identifiers the narrowest scope possible.

After you write a big program (and all its automated tests), you can time
them to find the real performance bottleneck. Replacing algorithms will have
a much bigger effect on performance than individual integers.

In this specific case, the compiler will most likely optimize. If it puts x
on the stack, x's address reserves when the function enters, as if x had
been declared outside the loop. If it puts x into a register, then it
doesn't reserve any stack. You will never be able to time a difference
between these minor adjustments.

 

[Victor Bazarov]

Is this:

int x;
for (int count=0; count<200; count++)
{
x = someFunc();
anotherFunc(x);
}


more efficient than this:

for (int count=0; count<200; count++)
{
int x = someFunc();
anotherFunc(x);
}

Both are less efficient than

for (int count = 0; count < 200; ++count)
anotherFunc(someFunc());

V

 

[Rolf Magnus]

Both are less efficient than

for (int count = 0; count < 200; ++count)
anotherFunc(someFunc());

I'd expect all three to be the same, or at least not significantly
different on any real-world compiler.

 

[Niklas Borson]

[quotes snipped]

Both are less efficient than

for (int count = 0; count < 200; ++count)
anotherFunc(someFunc());

Are you sure? It seems reasonable to expect an optimizing compiler
to generate identical object code for all three versions. VC does,
for example.

 

[Victor Bazarov]

[quotes snipped]

Both are less efficient than

for (int count = 0; count < 200; ++count)
anotherFunc(someFunc());

Are you sure? It seems reasonable to expect an optimizing compiler
to generate identical object code for all three versions. VC does,
for example.

Of course I am sure. How many fewer characters did I have to type
to get to the same object code? See?

 

[Risto Lankinen]

The second format will be optimized by your compiler to the first one.
I'd say the second runs as fast as the first, since declarations don't
need any processing.

Aren't these two sentences in slight logical conflict? I mean, if
one is as fast as the other, what would be the reason for the
optimizer to asymmetrically convert the second to the first one?

- Risto -

 

[Thomas Matthews]

[quotes snipped]

Both are less efficient than

for (int count = 0; count < 200; ++count)
anotherFunc(someFunc());

Are you sure? It seems reasonable to expect an optimizing compiler
to generate identical object code for all three versions. VC does,
for example.

Victor's example should compile faster (but whether
that's observable or not is another matter).

One issue with Victor's example is that the return
value from someFunc is hidden from a debugger and
hard to see (from most of them that I used). When
testing the code, I prefer to use separate
assignments. After the code works, I'll convert
it to Victor's example, if and only if the readability
is greater.

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.comeaucomputing.com/learn/faq/
Other sites:
http://www.josuttis.com -- C++ STL Library book

 

[Niklas Borson]

[quotes snipped]

Both are less efficient than

for (int count = 0; count < 200; ++count)
anotherFunc(someFunc());

Are you sure? It seems reasonable to expect an optimizing compiler
to generate identical object code for all three versions. VC does,
for example.

Of course I am sure. How many fewer characters did I have to type
to get to the same object code? See?

Fair enough.

 

[Niklas Borson]

[quotes snipped]

Both are less efficient than

for (int count = 0; count < 200; ++count)
anotherFunc(someFunc());

Are you sure? It seems reasonable to expect an optimizing compiler
to generate identical object code for all three versions. VC does,
for example.

Victor's example should compile faster (but whether
that's observable or not is another matter).

One issue with Victor's example is that the return
value from someFunc is hidden from a debugger and
hard to see (from most of them that I used). When
testing the code, I prefer to use separate
assignments. After the code works, I'll convert
it to Victor's example, if and only if the readability
is greater.

And of course, what one considers more readable is a
matter of style and opinion.

I used to favor really dense code. Over time, as
screens have gotten larger and my functions smaller,
I have come to prefer a less dense style. It's still
a judgment call in each case, but I am now more
likely than before to break up complex expressions
and assign intermediate results to named variables.