Creation of temporary objects in loop

[Jim Langston]

Which is more efficient (if either)

[Pseudo code]
MyHugeClass MyObject;
for ( int i = 0; i < 1000; ++i )
{
MyObject = SomeVal[i];
Use MyObject;
}

or

for ( int i = 0; i < 1000; ++i )
{
MyHugeClass MyObject = SomeVal[i];
Use MyObject;
}

That is, if I declare MyObject inside a for loop, does it get recreated
each iteration, or does the compiler create it once and reuse each time?

Or is it UB?

[Phil Endecott]

Jim Langston wrote:

Which is more efficient (if either)

You might get more accurate results by measuring it, rather than asking
here. It depends on many properites of your class and how you use it
(do the constructor/destructor do anything, is it modified while being
used, etc.). Here is my test program:
#include <vector>
#include <numeric>

using namespace std;

class HugeObject: public vector<int> {
public:
HugeObject(): vector<int>(500 00) {}
};

void use(HugeObject& h)
{
int t = accumulate(h.be gin(),h.end(),0 );
srand(t);
}

int main(int argc, char* argv[])
{
vector<HugeObje ct> SomeVals(1000);

for(int i=0; i<1000; ++i) {
HugeObject h = SomeVals[i];
use(h);
}
}

Platform: Linux, celeron-500, enough RAM, gcc-3.4, -O9.

real 0m8.916s
user 0m5.408s
sys 0m3.315s

Move the HugeObject h declaration outside the loop:

real 0m8.732s
user 0m6.597s
sys 0m1.969s

(Less system time probably means it spent less time doing low-level
memory allocation, presumably because it allocated in larger chunks.
But it makes up for that with more user time, for some reason. The
overall difference is not significant.)

Put the declaration back inside the loop but make it a reference. You
can only do this if you are not going to modify the copy, or don't mind
SomeVal also being changed:

real 0m5.427s
user 0m3.348s
sys 0m1.948s

Somewhat better.

But none of these are really significant differences. If you are
worried about the efficiency of your application you should be looking
for big-O complexity reduction, not this sort of change.

--Phil.

[dominiconnor]

I suppose I have to ask the question why you're doing this sort of loop
?
Hard to tell whether it's necessary, or whether you might be better off
dealing with
references/pointers.
Worth also suggesting that you might consider a const ref to the
object. This provides a strong hint to the compiler about how it might
optimise the code.

DominiConnor
Quant Headhunter

[Rolf Magnus]

Alf P. Steinbach wrote:

In general: it's not a good idea to worry about execution efficiency in
cases where you suspect the compiler might be able to do something.

In general: it's not a good idea to suspect the compiler might be able to do
something. If speed is not a concern, just ignore it, but don't assume
anthing about the optimization behavior. If speed is a concern, measure the
performance and maybe have a look at the generated code.

[Rolf Magnus]

Rene Moehring wrote:

On Mon, 20 Jun 2005 11:30:27 +1000, ben wrote:

"Jim Langston" <ta*******@rock etmail.com> wrote in message
news:wS******** *********@fe05. lga...

Which is more efficient (if either)

[Pseudo code]
MyHugeClass MyObject;
for ( int i = 0; i < 1000; ++i )
{
MyObject = SomeVal[i];
Use MyObject;
}

or

for ( int i = 0; i < 1000; ++i )
{
MyHugeClass MyObject = SomeVal[i];
Use MyObject;
}
It depends. But in most cases the first case will be more efficient
because the assignment is usually lighter than a copy constructor.

Besides the fact that no copy ctor is used.

Wrong. The second example uses a copy constructor to create a fresh copy of
SomeVal[i].
How can assigning be cheaper than a copy? The assignment in the first case
is a copy.

The object might need some initialization work that is done in the
constructor, but doesn't need to be redone in the assignment operator,
because the object is already constructed.

[Alf P. Steinbach]

* Rolf Magnus:

Alf P. Steinbach wrote:

In general: it's not a good idea to worry about execution efficiency in
cases where you suspect the compiler might be able to do something.
In general: it's not a good idea to suspect the compiler might be able to do
something.

That's folly.

And it's an attempt at countering something else than you replied to.

If speed is not a concern, just ignore it, but don't assume
anthing about the optimization behavior. If speed is a concern, measure the
performance and maybe have a look at the generated code.

That's good.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?