[RESOLVED] Faster to construct many times or construct once and assign many times?

Hey.

I have a for loop. Inside that for loop I pass a point to a function. The point is made from two integer values that are part of (declared and initialised inside) the for loop. I have the option to either create a point before the loop and then assign its x and y values manually each iteration:

Code:

---

point.x = x;
point.y = y;

some_func(point);

---

or construct a point each iteration from the two values:

Code:

---

some_func(point(x, y));

---

Premature optimisation aside, this is a question that I have asked myself many times before and I think it's time I chose the right option instead of wasting energy each time it happens pondering which is faster.

Thanks!

The only way you're going to get a definitive answer is to put together a test harness and time the two approaches. Never try to second-guess such fine differences.

The best thing to do is test it, since the answer to your question is compiler and system dependent. However, that said, on tests that I had done in the past with VS2005 on a P4, char's where certainly faster to construct than assign, and I think the same was also true for int's. I'm not sure about short's (on some systems, despite being two bytes, these are slower than int's). Doubles were faster to assign than construct.

Again, I stress, that testing is the best option since the answer to your question is compiler and system dependent. But, my general rule (which may be misplaced) is, built in types of 4 bytes or less where the value is different on each pass, I'll construct and initialise inside the loop, but anything else (including user defined types), I'll construct and initialise outside of the loop, and assign within the loop.

If you are really bothered about which is faster and want an absolute answer though, then profile it, and pick the most appropriate solution.

I assume that you are passing point to some_func by reference?

Quote:

---

Originally Posted by Graham

The only way you're going to get a definitive answer is to put together a test harness and time the two approaches. Never try to second-guess such fine differences.

---

Quote:

---

Originally Posted by PredicateNormative

The best thing to do is test it, since the answer to your question is compiler and system dependent. However, that said, on tests that I had done in the past with VS2005 on a P4, char's where certainly faster to construct than assign, and I think the same was also true for int's. I'm not sure about short's (on some systems, despite being two bytes, these are slower than int's). Doubles were faster to assign than construct.

Again, I stress, that testing is the best option since the answer to your question is compiler and system dependent. But, my general rule (which may be misplaced) is, built in types of 4 bytes or less where the value is different on each pass, I'll construct and initialise inside the loop, but anything else (including user defined types), I'll construct and initialise outside of the loop, and assign within the loop.

If you are really bothered about which is faster and want an absolute answer though, then profile it, and pick the most appropriate solution.

I assume that you are passing point to some_func by reference?

---

Ok. Seems I've found my answer. Are there any profilers that you'd recommend that work with Visual Studio? :) I'd be better off using a proper one than writing my own test code as at least I can use it again.

In the actual scenario, yes, I do pass point by reference to some_func.

I don't know of a free one, but the one I used in my old company to do the tests was DevPartner by Compuware. You can get a free trial version...

http://www.compuware.com/products/de...rk=200809-5755

Quote:

---

Originally Posted by PredicateNormative

I don't know of a free one, but the one I used in my old company to do the tests was DevPartner by Compuware. You can get a free trial version...

http://www.compuware.com/products/de...rk=200809-5755

---

Cheers. :)

i think its safe to assume that assignment is in most cases faster.
especially for classes that have dynamic allocation, strings, arrays etc.
unless it is a small POD.

This brings to mind Item #18 of Sutter and Alexandrescu's C++ Coding Standards: declare variables as locally as possible, but with an exception that it can sometimes be beneficial to hoist a variable out of a loop. However, their explanation of the exception is that "most of the time that won't obfuscate the code's intent at all, and it can actually help clarify what work is done inside the loop and what calculations are loop-invariant". That explanation does not seem to apply here since the work is indeed done inside the loop, hence "hoisting" the variable is just a matter of optimisation.

It REALL is a case for measurement (or at least careful analysis) and has no "correct" answer i the general case.

I have even found cases where:

Code:

---

Class basicInstance;
// Lots of setup for basicInstance
for (....)
{
  Class loopInstance = basicInstance;
    // Tweak this from the standard
    ....
}

---

is the fastest.

I agree with the premis of let "intent" be your initial guiding factor, and only deviate from that if you MEASURE a performance issue (you know my whole speech on that ;) )

[QUOTE=Mybowlcut;1798716]

Quote:

---

Originally Posted by Mybowlcut

Premature optimisation aside,

---

The best alternative is,

some_func(point(x, y));

It expresses your intent in the shortest and most restrictive way. It provides the compiler with more information about your intent than any other alternative and it thereby creates the most room for optimizations. This should guide your choise, not system dependent measurements.

If exactly this spot turns out to be a performance bottleneck then chances are that none of these choises will give the fastest code anyway. You most likely will do a rewrite of a larger section of code.

Quote:

---

Originally Posted by Mybowlcut

Ok. Seems I've found my answer. Are there any profilers ........

---

As I've argued in my previous post. Don't make a choise in cases like this based on system dependent measurements.

Quote:

---

Originally Posted by _uj

The best alternative is,

some_func(point(x, y));

It expresses your intent in the shortest and most restrictive way.

---

I agree. In fact, I would not call it an alternative, but rather the first thing that should be reached for since it follows the principle of declaring variables near first use.

Quote:

---

Originally Posted by _uj

This should guide your choise, not system dependent measurements.

---

How would you find the performance bottle neck without measurement?

Quote:

---

Originally Posted by _uj

If exactly this spot turns out to be a performance bottleneck then chances are that none of these choises will give the fastest code anyway. You most likely will do a rewrite of a larger section of code.

---

Wouldn't that depend on the (relative) cost of construction and assignment? It does seem reasonable to me that "hoisting" the variable out of the loop such that assignment is used instead of construction could be a valid optimisation.

Quote:

---

Originally Posted by _uj

The best alternative is,

some_func(point(x, y));

---

in this case yes, its a POD

if there is dynamic allocation, then this might not be prefered.

Don't forget that the optimiser may well hoist the declaration out of the loop for you (and in a more efficient way than you could achieve manually), so the point could well be moot.

Quote:

---

Originally Posted by Graham

Don't forget that the optimiser may well hoist the declaration out of the loop for you (and in a more efficient way than you could achieve manually), so the point could well be moot.

---

Are you serious? Are they really that intelligent?

Emphasis on the may. And, yes, I could see it as a possibility - after all, they can unroll loops if it's more efficient. Don't forget, optimisers have access to compiler implementation details that we don't.

Basically, my advice is: don't second-guess the optimiser; it's smarter than you.

Quote:

---

Originally Posted by Mybowlcut

Are you serious? Are they really that intelligent?

---

Without a doubt. Of all of the developers I know, there has been exactly ONE who could consistantly write code that outperformed the optimizations performed by the compiler (David Rainer). He is was the only person I have ever met who could keep track of Pentium Pipleline states, L!/L2 caching all while writing code.

As a side note, this is one of the big advantages in .NET. With C++ the optimizer is part of the compiler and only has access to the implementations available in the current coimpilation unit. While there are some "whole program optimizers", with .NET this becomes trivial, since ALL of the MSIL is available when the JIT compiler runs. Thius means that it can do such tricks such as cross DLL inlining, multiple level loop unrolling, and more.

I had a recent example of an 'obvious' optimisation not turning out to be any use.

Our code uses FFTs (Fast Fourier Transforms) which involve many repeated sine and cosine calculations. One 'obvious' optimisation is to pre-calculate the values and reuse them by using a lookup table.

Except that on timing the two methods there was NO DISCERNIBLE DIFFERENCE! Calculating a sine or cosine in a Core 2 Duo was no slower than using a lookup table!

To quote an old saying, "The proof of the pudding is in the eating".

Quote:

---

Originally Posted by laserlight

How would you find the performance bottle neck without measurement?

---

There's nothing wrong with using measurements to find bottlenecks in a program.

What I find to be a bad idea is to use measurements to choose between programming constructs while laying down code. This appearantly is what the OP plans to do. It's much better to use qualitative criteria. There's often a best choise which often also is the fastest.

Quote:

---

Wouldn't that depend on the (relative) cost of construction and assignment? It does seem reasonable to me that "hoisting" the variable out of the loop such that assignment is used instead of construction could be a valid optimisation.

---

It's my experience that often when a performance bottleneck has been found a more substantial change is required to remove it. (more substantial than some local tweaking).