|
The golden rule is to use a simple non-optimised algorithm initially, and only optimise it later if it turns out to be too slow.
However, sometimes I optimise from the begining if it's obvious that that non-optimised version is going to be inadequent. Also, if the optimised code takes no additional effort to code then I always use the optimised version.
|
|
|
|
|
I optimize exactly once. If I need to optimize an algorithm, I do it. And then that's how I'll write that algorithm from that point on, unless I really can't for some reason. This applies to patterns (algorithms with loose semantics).
I mean, why not reuse something that's proven to work reasonably fast?
--
Weiter, weiter, ins verderben.
Wir müssen leben bis wir sterben.
I blog too now[^]
|
|
|
|
|
Most optimizations can be down to good programming style.
Always using const references for parameters where appropriate etc.
Calculating intermediate results only the once etc.
Other than that, with todays PC speed, I dont think you really have to worry about it.
If you vote me down, my score will only get lower
|
|
|
|
|
Here's a question:
Roger Allen wrote:
Always using const references for parameters where appropriate etc.
I work with a guy who's a rabid over-optimizer. He also reviles the use of const, saying that he does not want to place any restrictions on his implementations.
I've given up on trying to get him to use const as a matter of good coding style, or as a courtesy to others on the team; however, I've thought about approaching this from the optimzation standpoint - but I don't fully understand how const references can improve code performance. Can you enlighten me on this, or point me to some references on the subject?
Thanks -
|
|
|
|
|
He can't be a rabid over-optimiser if he doesn't use const, he probably just fancies himself as an optimiser.
Const references are one of the most important optimisation hints, without which, the [compiler's] optimiser may just toss dice to decide which objects and pointers to keep in registers. VC++ no longer honours the register keyword, so const is all we have left.
To the optimiser, const is somewhat the opposite of register; instead of keeping the object in a register, it may specifically decide that object does not need to be, since it never changes. Thus, other objects are more likely to be kept in registers. Since more than one operation can execute on modern chips at once, things can be assigned from stack vars with little or no loss if there's something else that can be done in the meantime. But that's only part of the story.
const objects may also be temporary, can be calculated as needed (sometimes concurrently with other operations, to promote parallelism, which can double efficiency), and provide several other hints. In other words, const is an invaluable optimisation hint. If this guy really loves to optimise (he really should be judicious, since many things are done automatically by the compiler), he would step through critical loops in disassembly view as I do, and notice the benefits.
Personally, I've found const saved my arse many times, too. In coding frenzies (read "deadline"), I've occassionally had the compiler squawk that I tried to modify a const object, which forces me to fix it and avoid nasty bugs.
Cheers
|
|
|
|
|
IIRC, const references/const objects are generally not more optimized than ordinary objects. I read an article on this by some C++ hot shot, but I don't remember where I read it. 
const-correctness is a design strategy, enforcing read-only behaviours.
const int and the like are however replaced with compile time constants.
When I do pure C++, I try to use const as much as possible. It makes my code safe from feeble coding attempts on a late friday afternoon. However, I've been doing a lot of COM lately, where I can't use const in all it's splendor. I miss const. 
--
Weiter, weiter, ins verderben.
Wir müssen leben bis wir sterben.
I blog too now[^]
|
|
|
|
|
Jörgen Sigvardsson wrote:
I read an article on this by some C++ hot shot, but I don't remember where I read it.
You read it here[^], I guess.
And yes, I agree. Const-correctness is about correctness (pun intended), not optimization. But hey, if the only way to make a guy use consts is to tell him it is good for optimizations, then just tell him it is good for optimizations 
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
Nemanja Trifunovic wrote:
But hey, if the only way to make a guy use consts is to tell him it is good for optimizations, then just tell him it is good for optimizations
Child psychology for übergeeks 101.. 
When I think about it, const can be used as a tool for optimization. You can pass object parameters as const references, thus forcing the function to not modify the parameter or make a copy of it before it can do any modifications. 4 bytes on the stack vs X > 4 is an optimization I guess. But it's hardly because of some compiler magic, it's a purely hardware thingie.
Hmm.. a const ref is probably 8 bytes big on a IA-64 machine. Which could mean that passing const refs on such hardware is potentially less efficient than passing the entire object if it's smaller than 8 bytes.  I can already see optimizing geeks writing macros like
#ifdef __IA64__
#define CONST_REF(T) const T
#else
#define CONST_REF(T) const T&
#endif
void MyIA64OptimizedFunction(CONST_REF(ClassName) param)
{
...
}
template <typename T, bool RefYesNo>
struct ConstRefMaybeHelper {
typedef const T& type;
};
template <typename T>
struct ConstRefMaybeHelper<T, false> {
typedef const T type;
};
template <typename T>
struct ConstRefMaybe {
typedef ConstRefMaybeHelper<T, sizeof(T) >= sizeof(T*)>::type type;
};
void MyMuchCoolerIA64OptimizedFunction(ConstRefMaybe<ClassName>::type param)
{
...
}
--
Weiter, weiter, ins verderben.
Wir müssen leben bis wir sterben.
I blog too now[^]
|
|
|
|
|
Nemanja Trifunovic wrote:
You read it here[^], I guess.
If that's the article, then it actually does point out how const benefits optimisation in certain cases. Mostly in just examining very simple cases does it find no added benefit, as I mentioned elsewhere.
Curiously, he doesn't discuss loop constructs at all, where optimisers can really be put to the test (assuming a good-sized loop). He mostly talks about passing const pointers/references/objects, where relatively little execution time may occur. Bottlenecks frequently occur in multi-line loops, that involve several objects (high register contention). The majority of truly beneficial optimisations I've done over the years, have been within loops.
|
|
|
|
|
Jörgen Sigvardsson wrote:
IIRC, const references/const objects are generally not more optimized than ordinary objects. I read an article on this by some C++ hot shot ...
This depends on the code's complexity and the compiler itself. If there's little register contention or the optimiser can already figure out the best way to do things, const hints are superfluous.
However, when there's lots of register contention (specifically when the target is an x86, with only six general-purpose registers - seven if you omit frame pointers), the optimiser can make better use of hints like const. If someone writes a relatively simple algorithm, and compares assembler output with and without const, it would seem like there's little point in bothering, as the outputs are likely identical. Of course, that would be like concluding that since one's never been in a car accident, that air bags are not important.
There's little question, as you and other posters have pointed out, that const's greatest benefit is in protecting objects and avoiding nasty bugs. Yet, providing the compiler's optimiser with as many hints as possible, can improve the likelihood of more efficient output. Staying in the habit of using const means one never has to waste time thinking about whether it will matter in a particular case. So programmers like us never lose out.
BTW, I too miss const in situations where I can't use it.
Cheers
|
|
|
|
|
Jeff J wrote:
Staying in the habit of using const means one never has to waste time thinking about whether it will matter in a particular case. So programmers like us never lose out.
Except when we have to deal with other programmers who absolutely refuse to use it, and who throw fits if "their" code is modified...
|
|
|
|
|
Jim A. Johnson wrote:
programmers who absolutely refuse to use it
To be honest, this sounds strange to me. We have coding standards and code reviews, and if someone "refused" to follow the coding standards it would not (ehm) be very good for his career.
I think you guys have organizational issues if something like this can happen.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
Nemanja Trifunovic wrote:
We have coding standards and code reviews, and if someone "refused" to follow the coding standards it would not (ehm) be very good for his career.
Is your company hiring? Sounds like the managers are managing instead of leaving coders to fend for themselves. Now that seems strange to me. 
|
|
|
|
|
Jeff J wrote:
Now that seems strange to me.
LOL, then I must be lucky to work here. Actually, my managers are ex-developers themselves, and we were a "real" software development shop before being bought by a localization company, so we try to keep all the good practices we once developed. It's not easy, though
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
Nemanja Trifunovic wrote:
Actually, my managers are ex-developers themselves, and we were a "real" software development shop before being bought by a localization company, so we try to keep all the good practices we once developed.
I suspected as much, my friend. Ex-developers can make the best managers, as they understand what we must deal with. The worst managers and executives I've ever had to deal with, simply didn't understand programming or the language/platform.
I've gone through a few company buy-outs, and none of them have been easy. If they keep those managers and trust them, things will go much better. My support is with you in maintaining the developer's art and the quality of code into the 21st century.
Cheers
|
|
|
|
|
Jim A. Johnson wrote:
Except when we have to deal with other programmers who absolutely refuse to use it, and who throw fits if "their" code is modified...
Oh, do I feel your (our) pain, Jim!
This is a fickle field, where designers may dictate ludiculously rigid interface prototypes that don't always fit, and primadonnas insist their code is "perfect".
I must be very out of place: when others have fixed or improved my code, I invariably thank them (unless they botched it). Why shouldn't I? They've saved me time and aggravation, while giving "my" code a better reputation. But if someone helps them, they throw fits, even if the changes are documented. I guess that's what they call "team spirit".
Cheers
|
|
|
|
|
Before anything else, const is a modifier that speaks to the programmer who is reading the code that the object in question is not meant to change its state.
Maybe the compiler can use this as a side effect and make things more optimal.
Still, there is an optimisation that I always use.
// notice argument is "const reference"
// meaning "don't copy the string, just pass a pointer (aka a reference) to it"
// also meaning "i promise that I will not change the original value"
void printName( const CString& name ) <br />
{<br />
cout << name << endl;<br />
}
// here the name object is simply copied (copy constructor invoked)
// notice that at least, this version requires
// (a) construction
// (b) destruction
// (c) copy
void printNameCopy( CString name )<br />
{<br />
cout << name << endl;<br />
}
|
|
|
|
|
FWIW, CString's copy constructor doesn't copy the string data unless the source string is locked - so in most cases, there's not too much savings gained by passing a CString reference over value. However, as you noted it does eliminate the overhead of two method calls (constructor/destructor), and so in tight loops this may be a worthwhile distinction.
"The time has come," the Walrus said,
"To talk of many things..."
|
|
|
|
|
Shog9 wrote:
CString's copy constructor doesn't copy the string data unless the source string is locked - so in most cases, there's not too much savings gained by passing a CString reference over value
Very true, but replace CString by almost any class or structure following the "concrete data type" with or without "copy on write", and the savings (aka optimisation) remains.
My point, however, is this:
When you pass a "const reference" const X&, you save a lot.
- the called method does not have to test for a NULL pointer.
- construction and destruction are not needed.
- the intention is made clear to the ultimate audience: the programmer who maintains the code.
I must point out that often I pass a const pointer, for cases where an argument is optional and my method must deal with presence or absence of a parameter.
Going back on something months or years later, I can immediatly tell whats going on.
References, const or otherwise, are your friend!
|
|
|
|
|
you are hitting you head against wall :headbang: 
|
|
|
|
|
It makes a huge difference
<italic>Work hard and a bit of luck is the key to success. You don`t need to be genius, to be rich.
|
|
|
|
|
.. customers or testers complain about it enough...
An expert is somebody who learns more and more about less and less, until he knows absolutely everything about nothing.
|
|
|
|
|
I never optimize my code on the first pass at writing an app. I usually wait until it gets passed the first QA trials to see how it performs. If there are noticeable bottlenecks then I'll take a second pass at the code.
Over the years I've learnt what is optimal code for many situations, so my first pass code is probably better optimized than if I was just starting out as a developer. Although in things like SQL, I'm still learning faster ways of doing things.
Michael
CP Blog [^]
|
|
|
|
|
I learned never to optimize code in the first pass of the development.
If all errors have been fixed, you can start optimizing things.
I work mostly with realtime systems, and these are already very fast. Since there's no OS like Windows installed on these systems.
So optimizing has no use most of the time.
"Every rule in a world of bits and bytes can be bend or eventually be broken"
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
