Some (minor) optimizations to base lang.js

Monkey Targets Forums/HTML5/Some (minor) optimizations to base lang.js

Perturbatio(Posted 2011) [#1]


Main differences are in array resizing and the string join function, but also grouped var declarations together under 1 var statement where possible.

Not completely tested, but seems to work so far.

Presumably these can also be made to the actionscript file


Beaker(Posted 2011) [#2]
Here is a note I made recently (Actionscript, possibly js):

Completely untested.


marksibly(Posted 2011) [#3]
Hi,

What do these 'optimizations' achieve exactly?


Perturbatio(Posted 2011) [#4]
The join uses the browser's native array join which should be faster than js.

Grouping var statements at the top of the function is a very minor speed optimization since multiple var statements take longer to parse.

(http://wonko.com/post/try-to-use-one-var-statement-per-scope-in-javascript)

*EDIT*
also, using three equals === is faster since it doesn't do type conversion. (get a javascript console like firebug up and type "0 == false" and the "0 === false" to see)


Perturbatio(Posted 2011) [#5]
Another potential optimization is when you end up doing feature or browser checks, you can rewrite the function once you know what user agent you have and bypass the need to check each time (especially useful for heavily used functions).

i.e. something like:
var BB = {
	on:function(targetNode, eventName, func){
		if (window.attachEvent){//using IE
			BB.on = function(targetNode, eventName, func){//rewrite the function to use IE's attachEvent
				targetNode.attachEvent(eventName, func);
			};
		} else {//standards compliant
			BB.on = function(targetNode, eventName, func){ //rewrite function with addEventListener
				targetNode.addEventListener(eventName, func, false);
			};
		}
		BB.on(targetNode, eventName, func);//call the new, rewritten function
	} 
};

BB.on(b, "click", function(){alert('here')});



marksibly(Posted 2011) [#6]
Hi,

> The join uses the browser's native array join which should be faster than js.

OK.

> Grouping var statements at the top of the function is a very minor speed optimization since multiple var statements take longer to parse.

This doesn't sound right to me - JS will only be 'parsed' once into an intermediate format (or they wouldn't be able to get the insane speeds they do) so I don't consider this really worth the obsfucation.

However, I need to remember in general that JS locals aren't properly scoped...

> also, using three equals === is faster since it doesn't do type conversion. (get a javascript console like firebug up and type "0 == false" and the "0 === false" to see)

I thought this did 'identity' comparison? eg: x=5, y=5 but x===y is false as x & y are 'different'?

Not that I've ever used it...


marksibly(Posted 2011) [#7]
Hi,

> I thought this did 'identity' comparison? eg: x=5, y=5 but x===y is false as x & y are 'different'?

Actually, that's crap...but I do remember having some bizarre issues in php with ===, !== and the like, and ending up hating them with a passion!

But in general, before getting carried away with low-level opts like some of these, I'd kind of like to see some empirical evidence that they actually do something.

I'm a bit worried some of these ideas could do more harm than good - ie: declaring all your vars in one place *can* increase 'register pressure', ie: the chance of a register 'spilling' into memory since you have lots of vars 'live' at one time.

We had the same sort of thing happen in BlitzMax where everyone went byte crazy because 'everyone knows bytes are faster' - but not only are they not faster on 32 bit CPUs, there was also a lot of pointless 'masking' code being generated for the times they had to be converted to ints.

Modern JS engines are pretty awesome, and my inclination is to let them do their thing until we hit some kind of bottle-neck and THEN deal with it.


Beaker(Posted 2011) [#8]
Agreed. I just couldn't resist tho. It's your code and you need to be happy with maintaining it, but definitely worth a discussion tho.


Perturbatio(Posted 2011) [#9]
A pretty good explanation of why things like jslint recommend putting vars at the top:

http://stackoverflow.com/questions/1236206/one-var-per-function-in-javascript
The problem is that, whether you realise it or not, javascript invisibly moves all the var declarations to the top of the function scope.

so if you have a function like this
var i = 5
function testvar () {
     alert(i);
     var i=3;
}
testvar();

the alert window will contain undefined. because internally, it's been changed into this:
var i = 5
function testvar () {
     var i;
     alert(i);
     i=3;
}
testvar();

this is called "hoisting". The reason crockford so strongly advocates var declarations go at the top, is that it makes the code visibly match what it's going to do, instead of allowing invisible and unexpected behavior to occur.




Raz(Posted 2011) [#10]
Speaking from my PHP experience (may be different for js)

=== means the data type needs to be the same.

so

1=="1" would return true
1==="1" would return false because the first is an int, the second is a string


Perturbatio(Posted 2011) [#11]
=== means the data type needs to be the same.

it's the same in js.