optimization question
If you have some code like this:
pA->pB->someFunc1();
pA->pB->someFunc2();
...
pA->pB->someFunc10();
etc...
would it be faster to do it like this:
B * pHelp = pA->pB;
pHelp->someFunc1();
pHelp->someFunc2();
...
pHelp->someFunc10();
etc...
or does it matter?
it should be faster, as you dereference a pointer less per call.
Look for different things to optimize though, as something like this will not affect your total performance much.
Look for different things to optimize though, as something like this will not affect your total performance much.
Yeah it'll be faster, the running time of that code will probably go from 0.00000000075 seconds to 0.00000000072 seconds.
speed issues aside it can drasticly improve readability something that makes it well worth to do.
Of course, the compiler will probably do that kind of optimization for you, so you should concentrate on writing code that as clean and as expressive as you can.
It is unlikely to be faster in a release build unless pA or pB is declared volatile.
I'd write that code like this:
I'd write that code like this:
if(pA && pA->pB){ B& rHelp = *(pA->pB); rHelp.someFunc1(); rHelp.someFunc2(); ... rHelp.someFunc10();}else{ //error handling}
Quote:Original post by Nitage
It is unlikely to be faster in a release build unless pA or pB is declared volatile.
Wouldn't the compiler have to assume that pA could be altered by someFuncN(), i.e. pA->pB could point to something different afterwards? Anyway if you can demonstrate a realistic situation where it makes a noticable difference I'll be amazed. I can't remember who the quote is from, but "premature optimization is the root of all evil" :P
Quote:Original post by ZQJQuote:Original post by Nitage
It is unlikely to be faster in a release build unless pA or pB is declared volatile.
Wouldn't the compiler have to assume that pA could be altered by someFuncN(), i.e. pA->pB could point to something different afterwards? Anyway if you can demonstrate a realistic situation where it makes a noticable difference I'll be amazed. I can't remember who the quote is from, but "premature optimization is the root of all evil" :P
That would be a bug. If you are relying on that sort of behaviour you should be clean your desk out and get out of my office.
Quote:Original post by flangazorNobody said we would write code which does this, but it's all just code to the compiler[smile]. It'll compile it regardless, and is possibly unable to make certain assumptions.Quote:Original post by ZQJQuote:Original post by Nitage
It is unlikely to be faster in a release build unless pA or pB is declared volatile.
Wouldn't the compiler have to assume that pA could be altered by someFuncN(), i.e. pA->pB could point to something different afterwards? Anyway if you can demonstrate a realistic situation where it makes a noticable difference I'll be amazed. I can't remember who the quote is from, but "premature optimization is the root of all evil" :P
That would be a bug. If you are relying on that sort of behaviour you should be clean your desk out and get out of my office.
There is quite a strong case for this not being a premature optimisation too, because it actually saves a bit of typing if you follow what Nitage posted. (Which btw is what I also use sometimes). It's also marginally clearer.[cool]
Quote:Original post by Nitage
if(pA && pA->pB)
[...]
That code just made me think of something. Does the standard guarantee that logical expressions in if statements are processed left-right? From what I could find, the order is unspecified, so it is presumably unsafe to structure the conditional that way. It would be better as if( pA ) if( pA->pB ) [...]. Or will a decent compiler infer that it must check for pA before it checks for pA->pB?
Also, where can I find a recent online publication of the C++ standard? The best I could find was an ISO draft dated 1996.
jfl.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement