Re: [RESOLVED] Faster to construct many times or construct once and assign many times
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.
Re: [RESOLVED] Faster to construct many times or construct once and assign many times
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.
Re: [RESOLVED] Faster to construct many times or construct once and assign many times
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".
Re: [RESOLVED] Faster to construct many times or construct once and assign many times
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).
