very simple question

[aaragon]

Hi everyone,

I just wanted to know if there is any difference in performance in
declarating the variables in the beginning of a function or within for
loops. For example:

double test()
{
double a,b,c;
for(int i=0; i<n; i++){
a = i*10;
b = a-i;
c += a*b;
}
return c;
}

or:

double test()
{
double c;

for(int i=0; i<n; i++){
double a = i*10;
double b = a-i;
c += a*b;
}
return c;
}

 

[Victor Bazarov]

I just wanted to know if there is any difference in performance in
declarating the variables in the beginning of a function or within for
loops. [..]

There is no way to know before actually clocking both functions.

V

 

[Phlip]

double test()
{
double c;

for(int i=0; i<n; i++){
double a = i*10;
double b = a-i;
c += a*b;
}
return c;
}

Google "premature optimization". Always write the version that's easiest for
programmers to understand. Your second version makes a and b's role clear.

And, at the level of variable placement, there is almost nothing you can do
better than the compiler would do it. The compiler will probably optimize a
and b almost away, and will only use an FPU register, no matter where you
declare them.

 

[Jim Langston]

Hi everyone,

I just wanted to know if there is any difference in performance in
declarating the variables in the beginning of a function or within for
loops. For example:

double test()
{
double a,b,c;
for(int i=0; i<n; i++){
a = i*10;
b = a-i;
c += a*b;
}
return c;
}

or:

double test()
{
double c;

for(int i=0; i<n; i++){
double a = i*10;
double b = a-i;
c += a*b;
}
return c;
}

consider if n == 0. if n==0 for your second example the varibles would
never have to be allocated.

If they will always be allocated (n > 0) then the difference is assignment
..vs. initialization. For simple types (double, float, etc...) it probably
doesn't make much difference. For classes, however, it can if they have
constructors that take time.

The general rule in C++ is delcare varaibles just before you use them. One
of the main reasons is so you know what the variable is declared. If a
function is large and you come across
a = 10;
what is a? Is it int? double? char? a class? You'd have to scroll up to
the top of the function to find out. However
double a = 10;
makes it easier to read/maintain the code IMO.

 

[John Harrison]

Hi everyone,

I just wanted to know if there is any difference in performance in
declarating the variables in the beginning of a function or within for
loops. For example:

double test()
{
double a,b,c;
for(int i=0; i<n; i++){
a = i*10;
b = a-i;
c += a*b;
}
return c;
}

or:

double test()
{
double c;

for(int i=0; i<n; i++){
double a = i*10;
double b = a-i;
c += a*b;
}
return c;
}

Simple question, simple answer. No difference at all.

Let the compiler take care of optmization. In fact if you declare your
variables where they are used it is EASIER for the compiler to optimise
your code.

Concentrate on writing good clear code, computer time is cheap,
programmer time is expensive. Try to optimize the latter not the former.

john

 

[Zeppe]

Simple question, simple answer. No difference at all.

Let the compiler take care of optmization. In fact if you declare your
variables where they are used it is EASIER for the compiler to optimise
your code.

Concentrate on writing good clear code, computer time is cheap,
programmer time is expensive. Try to optimize the latter not the former.

I agree with you. A couple of notes, though:

1) from time to time there are optimizations that the compiler can't do
so easily. For example, if the variables are classes with a non-trivial
constructor, I don't think the compiler will try to understand if the
behaviour is the same calling the constructor just once or for each
step. Anyway, this kind of optimization has to be done once the program
is complete and working, testing the changes for the performances. At
the moment of writing, just put a bookmark in that piece of code.

2) Allocating an integer in the stack in most architecture is a matter
of subtracting the size of the integer from the stack pointer, and this
just if the compiler doesn't optimize the code. So, in the example
originally posted the difference would be really negligible anyway.

Regards,

Zeppe

 

[asterisc]

aaragon a scris:

Hi everyone,

I just wanted to know if there is any difference in performance in
declarating the variables in the beginning of a function or within for
loops. For example:

double test()
{
double a,b,c;
for(int i=0; i<n; i++){
a = i*10;
b = a-i;
c += a*b;
}
return c;
}

or:

double test()
{
double c;

for(int i=0; i<n; i++){
double a = i*10;
double b = a-i;
c += a*b;
}
return c;
}

Hello,

C++ idioms tells that you should declare variables very close where
you need to use them. For simple types there is no big difference, but
when you use objects, declaring variables will call constructors which
can allocate memory and will slow down the application pretty much.
It all depends of what you need to do.

 

[Gianni Mariani]

Hi everyone,

I just wanted to know if there is any difference in performance in
declarating the variables in the beginning of a function or within for
loops. For example:

double test()
{
double a,b,c;
for(int i=0; i<n; i++){
a = i*10;
b = a-i;
c += a*b;
}
return c;

}

or:

double test()
{
double c;

for(int i=0; i<n; i++){
double a = i*10;
double b = a-i;
c += a*b;
}
return c;

}

In this case, none whatsoever on all compilers I use - YMMV. However
if the objects created in the loop have a non-trivial constructor (or
a constructor that can't be optimized away to nothing), then it can be
quite expensive to have them constructed in the loop.

 

[Bo Persson]

Gianni Mariani wrote:
::: Hi everyone,
:::
::: I just wanted to know if there is any difference in performance in
::: declarating the variables in the beginning of a function or
::: within for loops. For example:
:::
::: double test()
::: {
::: double a,b,c;
::: for(int i=0; i<n; i++){
::: a = i*10;
::: b = a-i;
::: c += a*b;
::: }
::: return c;
:::
::: }
:::
::: or:
:::
::: double test()
::: {
::: double c;
:::
::: for(int i=0; i<n; i++){
::: double a = i*10;
::: double b = a-i;
::: c += a*b;
::: }
::: return c;
:::
::: }
::
:: In this case, none whatsoever on all compilers I use - YMMV.
:: However if the objects created in the loop have a non-trivial
:: constructor (or a constructor that can't be optimized away to
:: nothing), then it can be quite expensive to have them constructed
:: in the loop.

On the other hand, if the constructor is expensive, so is possibly
also the assignment operator. In that case, we cannot generally tell
if it is cheaper to change the value of an object, or create one from
scratch with the right value.

The advice is to not bother until you notice that this actually is the
bottle neck in your program. It usually never is!

I would go for option 2, because I think it looks better. That makes
it easier for me to understand.


Bo Persson

 

[peter koch]

aaragon a scris:









Hello,

C++ idioms tells that you should declare variables very close where
you need to use them. For simple types there is no big difference, but
when you use objects, declaring variables will call constructors which
can allocate memory and will slow down the application pretty much.
It all depends of what you need to do.

Well... that constructor call does useful work - initialising the
object to a well-known state. For an object declared at an outer
scope, some amount of work would have to be done getting that same
initialisation. You'll often find that that other work results in
slower code than using the straight forward non-obscuring method of
declaring the variable where it belongs.

/Peter

 

[osmium]

Well... that constructor call does useful work - initialising the
object to a well-known state. For an object declared at an outer
scope, some amount of work would have to be done getting that same
initialisation.

That presumes you actually *want* that state. If some humongous tree is
already in RAM, or some equivalent, you don't necessarily want a replacement
tree. I am sure there are cases where your point is valid, but I think it
needed qualifiers.

You'll often find that that other work results in

 

[aaragon]

That presumes you actually *want* that state. If some humongous tree is
already in RAM, or some equivalent, you don't necessarily want a replacement
tree. I am sure there are cases where your point is valid, but I think it
needed qualifiers.

You'll often find that that other work results in

Thank you guys for your help. I'll finally go with the second option.

 

[Greg Herlihy]

In this case, none whatsoever on all compilers I use - YMMV. However
if the objects created in the loop have a non-trivial constructor (or
a constructor that can't be optimized away to nothing), then it can be
quite expensive to have them constructed in the loop.

But if constructing the object is expensive, then assigning an already-
constructed object a value is likely to be even more expensive (And
yes, that observation might sound counter-intuitive). But in fact it's
probably safe to say that most C++ programming books (include Meyers'
"Effective C++") advise their readers to prefer construction-
initialization over assignment. So, unless there is some specific
reason for doing otherwise, declaring the objects within the for loop,
will likely turn out to be the more efficient choice.

Greg

 

[Lionel B]

But if constructing the object is expensive, then assigning an already-
constructed object a value is likely to be even more expensive

I can think of one (common?) case where this is not likely to be so: when
construction involves expensive memory allocation and assignment does not
require that memory be re-allocated (eg. construction of a large vector
and assignment from a vector of the same or smaller size).

(And yes,
that observation might sound counter-intuitive). But in fact it's
probably safe to say that most C++ programming books (include Meyers'
"Effective C++") advise their readers to prefer construction-
initialization over assignment.

In general, yes...

So, unless there is some specific reason
for doing otherwise, declaring the objects within the for loop, will
likely turn out to be the more efficient choice.

Perhaps the situation I suggest above supplies one such "specific reason".