Are we talking of programming?
Or are we talking of scripting?
It is the all important detail you seem to be forgetting.
Maybe you just lost focus. It happens.
The only way of coding-for-speed, in nwscript, is to write your code so that it uses as less instructions as is possible.
<< The fastest code is that which does not run >>
Self-explanatory, I am sure.
High Level? Low Level? All meaningless.
Using switches to do this? Then it is bad because the user will likely use another switch to do that...?
Did you know that a switch are if-else in disguise in nwscript?
It has the constraints of the switch (they managed to bug that too, btw) but always if-else they are.
Nwscript is a script language. Interpreted by a Virtual Machine.
High Level by design, and Slow by definition.
Every single instruction in your NSS shall evaluate to a whole function call in the VM. Complete with pushing and popping of args on the stack then cleanup according to the calling convention. These things are not for free. They happen continually and do eat up cycles.
There is no such thing as "atomic" in this context, for you do not run directly on the metal -- but on an abstract software layer that is far away from it (and I bet the interpreter itself is far from optimized for speed).
So what is all this fuss about writing faster code?
The only way to go fast in nwscript is to write less.
At the end of the day it will matter the amount of instructions within the NCS file (and in case of loops, the less iterations the better)
Lesser = Faster.
That is a direct measure of how fast your code is.
Everything else is chit-chat.
You may invoke the pow() to calculate a power of 2... Or you may do a left shift directly.
In nwscript both things will set in motion a slow function call.
The speed gain of a cheap left shift will be absorbed. And unless you wrap them in a tight loop, you are not going to measure any sensible boost by using either method.
In this context, you see, writing code that is easy to read and maintain is the best move anybody can do.
Especially if we consider that most users here do not chew the language comfortably.
Finally, take a look here:
int a = 205761315;
a *= 6;
int b = 205761315;
b <<= 1;
b += b << 1;
Unless you use an optimizing compiler, the b way is going to outspeed the a way anyday. Right, on the CPU.
But in the nwscript VM the a way is going to be about 4 times as fast as the b way.
(***)In nwscript only the instructions count does matter.
The more data manipulation and calculus you do "outside" of the script layer, the faster you go.
[edit]
I forgot the conclusion. So much writing and too little re-reading.
(***) = With the uber CPU we got today hardly you are going to appreciate a speed difference unless it is something remarkable. What is the ponit of squeezing your brain to write uber code, when someone else can write something quasi-as-fast and in 1/10th the time you did your? Off putting thought, to be ure, but that is the reality we are facing with modern hardware. Might be better to employ one's expertise to write code that is easier to read and maintain (comments also help in that snse, of course).
-fox
Modifié par the.gray.fox, 03 juillet 2011 - 05:13 .
