Which is faster…
private var soundOn = PlayerPrefs.GetInt("soundOn");
function Update()
{
if (soundOn == 1) updateSound();
}
OR
private var soundOn = false;
function Start()
{
if (PlayerPrefs.GetInt("soundOn") == 1) soundOn = true;
else soundOn = false;
}
function Update()
{
if (soundOn) updateSound();
}
Yeah, i know I’m getting a tad ridiculous, but I’m an optimization whore.
Certainly in other languages, and I’m assuming “Unityscript” is no different, you can still use:
if (soundOn) {}
when dealing with an int value.
A 0 (zero) will return false, and any other positive value (e.g. 1) will return true.
So your second code example just seems to add fat.
So the following is what I’d go with.
private var soundOn = PlayerPrefs.GetInt("soundOn");
function Update() {
if (soundOn) updateSound();
}
While it’s true that 1/0 and true/false are generally interchangeable in JavaScript, I think that using a boolean vice an int might be slightly better RE optimization because, as I understand it, more memory is allocated for an int than a boolean. I think the difference is minimal, almost negligible, but if you’re trying to optimize to the Nth degree it matters.
Also, I’m not sure if it’s true or not I think I read somewhere that booleans get processed faster than ints.
At any rate, I’ve also considered basically this same situation and usually go with what amounts to your second code chunk.
Using ints instead of bools, regardless of speed, makes for ugly code. Why not
private var soundOn = PlayerPrefs.GetInt("soundOn") > 0;
:?:
Ruining the readability, maintainability and increasing error proneness of your code for microscopic speedups is an extremely bad idea.
Even on the iPhone, there is absolutely no way the difference between bool or int comparisons (if any) are going to make any measurable difference on the framerate.
What difference does it make ? You are using javascript to begin with.
I realize you’re new here. Read over this page.
If statements take a bool. Therefore a bool is microscopically faster as it does not need to implicitly cast to a bool at any point. Although the Compiler will probably make both of them identical, kinda like how if(sound) and if(sound == true) are identical once compiled.
Regardless if you want to optimize, that is not the place. No matter what you do you will see no visible effects.
It’s like trying to optimize the weight of your socks in a jet fighter plane (don’t wear heavy winter socks the weight will slow you down!) to see if it goes faster. Technically it will. Realistically it won’t.
The fact that the code gets JITed into native binaries is irrelevant.
Worrying about such micro optimizations when you are giving up control of your code/cache layout in the first place, is just silly.
There is nothing wrong with using javascript but in doing so you are implicitly making an assumption that it won’t contain any performance-critial code to begin with.
If it does and you need to resort to low level optimizations to speed it up, then you shouldn’t be using javascript in the first place.
While I agree with the general sentiment, (such extreme micro-optimizations are somewhat irrelevant in managed code, and if it’s that important you should really be using something more low level). It’s important to note that Boo, C#, and Javascript in Unity get compiled down to the same Mono (.NET) code. It’s not real javascript, but merely a syntax lookalike to convert into CIL.
So no need to pick on Javascript in particular, as any Unity scripting language has the same back end system.
Loss of generics alone and being forced into boxing/unboxing is reason enough to go C# for performance.
This just isn’t true (unless you’re suggesting not using Unity at all). JavaScript can be slow, but only if you’re not tuning things properly. You’d hope that a senior developer at UT would know what he’s talking about.
Hey, I use C#. But there’s no reason that Unity’s JavaScript can’t have generics. It just hasn’t been implemented yet (or it hasn’t been documented).
Precisely … when using Unity you essentially letting them handle performance critical stuff inside their black-box components while you just write glue-code/logic etc.
That’s the whole point of using it to begin with - no need to worry about low level performance etc
I’ll disagree there. Nobody can make a modern game without tools comparable to Unity, without being on a gigantic team. This isn’t an issue of going to a restaurant instead of cooking because you’re lazy.
There’s no reason not to use good practice just because you want to make a game by yourself or with a small team. The topic of this thread might not make any difference, but there are a whole lot of things that you can slow down just by not following good practice, e.g. what was described in the first link in my last post. Just find a balance of creating with performance and energy use in mind, and actually getting things done.
That’s not even remotely true. Pretty much all the optimizations you’d use in C# apply equally well in Javascript. (Especially in Unity 3, given that stuff like generics is implemented in JS.) We’re talking about Unity iPhone here, which has no dynamic typing in JS, so the “black box” stuff doesn’t exist.
Unity3 has generics in JS, and you never were forced into boxing/unboxing in any case.
–Eric
I would like to point out here, that I was merely curious.
Real optimisations come down to doing as little as possible, allocating as little memory as possible and avoid sloppy typing.
I was not aware I could do that 
I imagined that a boolean would be faster, because I don’t see why it would need to allocate more than a single bit, whereas an Int would allocate more.
At any rate, I can’t imagine such a trivial optimisation having any real effect outside of ridiculously contrived benchmarks
Or you could use BoolPrefs.
private var soundOn = PlayerPrefsX.GetBool("soundOn");
You can’t allocate a single bit; the least you can allocate is a byte. However this is likely to be slightly slower than using 4 bytes due to the way CPUs usually work. (There is however a BitArray class which would be more memory-efficient than a boolean array.) In any case, you can always see for yourself by running a benchmark, although the correct answer in this case, as stated earlier, is “use whatever’s most readable” since the difference isn’t enough to matter.
–Eric
I am not talking about Javascript specific boxing/unboxing issues …
I am talking about opaque components written in optimized C ( with further parts, I suspect, written in optimized ARM asm with special Neon/VFP paths) which constitute the actual engine.
You wouldn’t want to write code manipulating vertex arrays on per frame basis in javascript ( compiled or not) and that’s the kind of code when micro-optimizations actually make sense.
Actually, I do want to do that, and I have done so with good results, although I haven’t tried it yet on the iPhone. (e.g., the terrain engine in Unity is mostly C#.)
–Eric
Sure,you can do whatever you want … you can even write a rayracer in Lisp …and sometimes it will be enough.
It is simply a matter of proportion.
If you write some code in javascript which transforms a mesh 30 times per second, it may be good enough for whatever you are doing but on the other hand, if someone else writes the same code in optimized asm code and it runs 5 times faster, he will have 5 times as many CPU cycles left to stream more vertices to the GPU , have more detailed physic models or perhaps simply don’t burn so much power while doing the same work.