Which is faster?
-
Yes, I can care. Anyway I wouldn't use a debug build for a speed test. :)
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles]Just for you ( :) ), here are the results of a release build with "default" optimization (for speed): <1a> 0.0000022349 sec <1b> 0.0000019556 sec <2 > 0.0000019556 sec ---------- <1a> 0.0000016762 sec <1b> 0.0000016762 sec <2 > 0.0000016762 sec ---------- <1a> 0.0000016762 sec <1b> 0.0000016762 sec <2 > 0.0000016762 sec ---------- <1a> 0.0000016762 sec <1b> 0.0000016762 sec <2 > 0.0000019556 sec ---------- <1a> 0.0000016762 sec <1b> 0.0000016762 sec <2 > 0.0000019556 sec and with optimizations turned off: <1a> 0.7622823571 sec <1b> 0.7618152586 sec <2 > 0.5077494486 sec ---------- <1a> 0.7632852779 sec <1b> 0.7537491497 sec <2 > 0.5121279380 sec ---------- <1a> 0.7620644523 sec <1b> 0.7755153239 sec <2 > 0.5118524840 sec ---------- <1a> 0.7574504581 sec <1b> 0.7570453787 sec <2 > 0.5195719009 sec ---------- <1a> 0.7594526679 sec <1b> 0.7610942173 sec <2 > 0.5190137294 sec [EDIT] I wonder where the "variance" of the time needed for the 2nd method comes from with optimizations applied.
> The problem with computers is that they do what you tell them to do and not what you want them to do. < > "It doesn't work, fix it" does not qualify as a bug report. < > Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
-
Just for you ( :) ), here are the results of a release build with "default" optimization (for speed): <1a> 0.0000022349 sec <1b> 0.0000019556 sec <2 > 0.0000019556 sec ---------- <1a> 0.0000016762 sec <1b> 0.0000016762 sec <2 > 0.0000016762 sec ---------- <1a> 0.0000016762 sec <1b> 0.0000016762 sec <2 > 0.0000016762 sec ---------- <1a> 0.0000016762 sec <1b> 0.0000016762 sec <2 > 0.0000019556 sec ---------- <1a> 0.0000016762 sec <1b> 0.0000016762 sec <2 > 0.0000019556 sec and with optimizations turned off: <1a> 0.7622823571 sec <1b> 0.7618152586 sec <2 > 0.5077494486 sec ---------- <1a> 0.7632852779 sec <1b> 0.7537491497 sec <2 > 0.5121279380 sec ---------- <1a> 0.7620644523 sec <1b> 0.7755153239 sec <2 > 0.5118524840 sec ---------- <1a> 0.7574504581 sec <1b> 0.7570453787 sec <2 > 0.5195719009 sec ---------- <1a> 0.7594526679 sec <1b> 0.7610942173 sec <2 > 0.5190137294 sec [EDIT] I wonder where the "variance" of the time needed for the 2nd method comes from with optimizations applied.
> The problem with computers is that they do what you tell them to do and not what you want them to do. < > "It doesn't work, fix it" does not qualify as a bug report. < > Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
Thank you, sir. :)
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
The only way to find out is to write some tests, compile and run them on your system. Arguing thoretically about what's faster is fairly pointless. Cheers, Ash
Wrong. The only way is to create the .COD file and see what the compiler generates for that code, then with a debugger, see what load time optimization may be done during loading. It is this final machine code that tells the story during execution. Dave.
-
Wrong. The only way is to create the .COD file and see what the compiler generates for that code, then with a debugger, see what load time optimization may be done during loading. It is this final machine code that tells the story during execution. Dave.
CAVEAT: This doesn't apply if you're talking about embedded systems where you have a greater degree of control over what's running. On your average desktop looking at an assembly listing won't tell you how fast a piece of code runs. It might give you an idea, might even tell you some idea of the relative speed [1] and where you could speed it up if you wanted to manually code it but won't tell you how fast it actually runs. As for "load time optimisation" I'm not sure what you mean in this context but load time shouldn't be a factor in measuring how fast a particular lump of code runs. Load time is long over by the time you start measuring how fast a particular piece of code runs. Cheers, Ash
