nodejsbot

Javascript Performance

2010-11-14T08:53:00.001-08:00

The Javascript community does not often need to concern itself with speed, but here it goes. I am going to cover: Runtime Code Generation, Language Oddities, Lies, and Memory Consumption. If you want to go over some more general topics such as caching values, I suggest Google as these topics are more than I can truly cover in a single blog post as it is.

Runtime Code Generation:

This is one of my favorite features if I know that I am going to run a piece of code a huge number of times but only need to read the parameters once. This one time parameter (or constant parameters) lets me spend some time compiling code. NOTE: you should not abuse code generation and do it all the time.

How to use it:

Function / eval are the only ways to do this in Javascript. They do not generate sub-optimal performance functions (see: http://jsperf.com/function-vs-constructor-vs-eval). The functions generate code that is as fast as anything else. I would highly recommend using Function instead of eval. Using Function does not allow access to variables outside of your function except parameters and the "this" variable.

Example:

A simple cache function for a CSS selector like language (only takes tags and ids, is buggy etc.)

function SelectorFunction(selector) {
var src = String(selector).match(/\#?[^a-zA-Z_\-$0-9]/g)
src.map(function(selector_item){
return selector_item.charAt(0) === "."
? "child = document.getElementById(\"" +selector_item.slice(1)+ "\"); if(child.compareDocumentPosition(node) !== Node.DOCUMENT_POSITION_CONTAINED_BY) return undefined; node = child"
: "node.getElementsByTagName(\"" +selector_item+ "\")"
})
return Function("node","var child = null;" + src.join(";"))
}

When to use it:

When you have time to spare (setup / idle time / etc.)
You know you are going to be able to infer something from your parameters that lets you hard code or pre-compute values

Pros:

If done right, your code will gain quite a bit of speed and help remove possible bottlenecks
Caching precomputed values means parsing them again wont occur and wont use up memory in the process

Cons:

If abused, this will slow down your code
Cached values may not be wanted for some things (dynamic settings)

Language Oddities

As a language Javascript has some odd performance characteristics.

This / Closures:

Some engines, v8 in particular, aggressively optimize the lookup operator. You cannot do that optimization on a this variable since it is an unknown at compile time for some other inferences.
Closures are faster than the this variable lookup time in v8.
Closures that completely hide another closure will skip the closure above it in a scope chain (except function arguments and the catch variable in v8, this cannot be done to escape a with statement)

Numbers:

Javascript is terrible at bitwise operators, TERRIBLE. Especially if you start mixing them with numbers that are acting like floating point numbers (this is the default number system in Javascript, engines optimize when you swap into integral calculation to prevent multiple casts over and over again).

Operators:

The in operator is slower than the lookup operator. Why? It checks the entire prototype chain. The lookup operator in most new engines only performs a single check.
The if statement is slower than the ternary operator which is slower than the or operator for single expression results (http://jsperf.com/default-args-or-vs-if/2)
Avoid the delete operator unless you have an extremely long lived object. V8 will have to do some hoodoo in the background if you use it to reconcile some lookup optimizations which will take time.

Statements:

The with statement is slow... I mean really slow. Slower than emulating it with the dot operator (which means something slightly different, but oh well). This is because it must check the entire prototype chain of the object (akin to the in operator), and because almost no engine optimizes this statement due to its lack of use.
Switch statements are fast, but unless you are only using Strings if/else branches can be optimized better by most engines.

Lies

A lot of what I have read about Javascript meta-programming is a lie.

If statements will not be precomputed and cached. They however are often
Objects as hashes only work until a certain size limit. Then they start to slow down due to GC (13~ million properties in the current v8, but then again who gets that far?).
StringVariable + "". This is the devils work for performance. It creates a full copy due to .toString etc this cannot be optimized out.

Memory Consumption

A lot of people do things that seem innovative, but tend towards high memory consumption.

Buffering! Do not do this when you only are going to pump out the data at the end! (In some cases you do not know if you want to pump it out if there is an error).
Throwaway functions do take memory, don't abuse them, cache them if you can (well cache everything you can really).
Please don't save extra properties onto host objects. Host objects tend to have slightly different GC rules (in IE 6-8 you can leak when messing with dom and not cleaning up!).
Avoid globals! Globals will never be GC'ed just avoid them when you can (certainly if you are leaving an object that can grow and grow and then be unused).

Javascript "Classes"

2010-11-08T12:37:00.000-08:00

I would like to take some time to talk about a common JS misconception. "Faux Classes make JS easier." AKA beginning OOP in Javascript.

First off let me note:

"Javascript does not contain nor can it truly emulate multiple inheritance, interfaces, namespaced privileges, declared throwing, or namespaces" (email me if you want really stupidly in depth evidence and opinions on anything you consider false in that)

Ok. But aren't those nice to have?

In many languages yes, in JS, they are not needed. Most implementations of these are approximations, and offer less performance than their pure JS counterpart.

Why?

1. They are not built in, and the way JS was designed run-time checking is going be costly / assume things / etc.

1. 1. Assuming things is fine! I want my classes!

No, you don't. Learn the language, understand what you are asking. Don't learn JQuery or Dojo or ExtJS ... learn Javascript (Ecmascript to be picky). Javascript is nicer than you think, don't make it esoteric by having a metalanguage (talk to me about C preprocessor if you want to argue this).

1. 2. In my time looking at the job market recently, I have noted many companies have taken the plunge and depend upon these systems... Makes getting a job hard, makes employing people harder, and in general means if there is a design problem with your system you chose for a problem, you are boned.

2. Most of these are actually harder to maintain than their JS counterparts! I cannot stress this enough. If you cannot absolutely follow a system for 100% of your project, interacting with other systems will become painful, even interacting with normal JS can be painful!

Fine, whatever, they are prettier to read.

+1 for classes if done right. (Coffeescript, arguably not really JS)

Ok, so they are pretty and I don't need to understand JS inheritance or prototypes.

-1 for classes. You will need to learn these at some point or your application will slowly bloat.

Classes are more performant than prototypes!

No. Long blog post coming in next couple days on performance in JS.

I cannot stress this next point enough, you do not have to work with foo.prototype for every property. For my sake, for your sake, for our sake:

function foo(){}
foo.prototype = {
bar: function(){},
baz: function(){}
};

But how do I do inheritance?

function bar() {}
bar.prototype = new foo();

bar will have all the default prototype values of a default constructed foo. do not mix this and the one above, however, you may consider making your extension into a function itself.

function give_bar_methods(proto) {
proto.shazam = function () {}
}
function bar() {}
bar.prototype = new foo();
give_bar_methods(bar.prototype);
//now all bars get shazam!

prototypes the way they are in JS have an amazing ability RUNTIME MODIFICATION. Oh yea, thats right. Its awesome.

var x = new bar();
bar.prototype.y = function() {return 6}
x.y() //6

This can be extremely useful with lazy loading and some runtime codegen.

Node's require()

2010-10-07T21:04:00.000-07:00

Node has a require function that is not entirely the same as the CommonJS one. And I for one am glad. CommonJS has a very strict very unflexible require. So, I am here to write how require works in node.

Modules imported by require are cached on absolute file path
Modules imported by require are not reloaded when required again unless you mess with very low level bits of node
Modules have their own scope
Modules have 3 means of exporting variables

exports.x = 'y' - would use the default Object for exporting provided by node and add an 'x' property with value 'y'. require of this module would gain require(__filename).x === 'y'
module.exports = [1,2,3] - would override the default Object provided for exports for something else (generally a function or a different object). This would replace all the exports you have already done and would make the require export an array with 1,2, and 3 instead.
global - if you don't have a good reason, and i mean, damn good, don't attach a property to global

require.paths - contains all the paths to search for non-absolute/non-relative requires
the correct way to add a path to require.paths is to use require.paths.unshift(__dirname)
require.main will be true if you are in the main module for a node process
require is a unique function for each module, passing it around between modules is ill advised
require checks for many things when picking what file to pull in

File at absolute path
File at path+".js"
Directory at path with "index.js"

Javascript Primer

2010-09-16T19:38:00.000-07:00

Many people are learning JS when learning node here is a primer on what to learn outside of syntax. Learn them well...

Variables:

When you reference a variable in JS it can be a reference type (Object, Array, Function) or a value type (String, Number/NaN/Infinty, Boolean, null, undefined). The variable name itself is typeless and can be considered a reference rather than any sort of direct relation to the data it holds. The important difference is how data is copied when assigned to a new variable.

Reference types may exist in multiple places at once being modified in place affecting all places. Assignment is not a copy operation.

Value types exist as they are and may not be modified in place. This means you make new copies of them for every modification you perform. Assignment is a copy operation on the reference to an immutable value.

ALL operations except lookup '.' and invocation'(...)' attempt modification that ensures copying. Lookup and invocation operations do not modify in place (although the actions of invocation may change what the variable reference holds as its data).

Scope:

Variables in javascript are given a scope that they exist in any operation in that scope will retrieve the variable with the name referenced regardless of where / how many times you declare it. New scopes are created in only 1 situation inside of a function. JS scopes are not based upon {}s like some languages.

ie.

function foo() {
var i = 0
if(i === 0) {
var i = 1
}
return i
}

there are not 2 variables 'i' there is only one, i will equal 1 when it is returned, because there is only one scope. do not attempt to use {} for a new scope!

*Function arguments exist in local scope

*With statements create a pseudo scope:

inside of a with statement any property of the argument is available as if it was in a scope above the current one. it does not create a new scope however.

*Catch statements provide a temporary variable:

inside of a catch statement the argument reference is available, but it is not assigned to the variable reference in the current scope. it does not make a new scope , but it may hide a variable in the current scope temporarily.

Closures:

Remember scope? Well in JS all scopes above (outside of but not next to) your scope will be tried for when resolving a reference. This lets you pass around variables in interesting ways since functions can be created inside of a given scope. This detachment of scope is called a closure. Even if a function leaves its own scope by being referenced elsewhere it retains its original scope!

ie.

var function_array = []

for(var i=0;i<50;i++){

function_array[i] = function() {return i}

}

all functions in function_array return 50. When they execute they retain their scope, and since for does not make a new one, they share i.

Prototypes:

The actual knowledge

Javascript is a prototypal language. You make what you want the default object to look and act like and you go from there. However, JS does give you something that many prototypal languages do not, constructors.

In JS Functions are how we create objects. All you do is new foo(...) means :

create an object that has default values of foo.prototype
give it a prototype chain that holds foo.prototype's prototype chain
run the following statements with the 'this' variable temporarily set to the object being created

Since prototype properties are default values that are applied before the constructor executes, do not set up your prototype inside the constructor (unless you are doing something very very odd). Set it up outside the constructor, or else you will be redeclaring your defaults many times and since it is a shallow copy, possibly even wreaking havoc if you do so.

*The instanceof operator

If a function changes its prototype by assignment directly (foo.prototype = {}) its prototype chain is lost and instanceof will fail where it would have worked previously.

In JS there are many arguments of whether classes exist or not (Wikipedia).

The argument that classes exist

Javascript allows the creation of Object that may inherit properties from other objects in a chain. That by definition is the smalled type that may be associated in a JS execution. They are neither Object's in the sense that they rely on inheritance and neither types due having instance methods and properties.

The argument that classes do not exist

Classes imply things about languages after years of use to some of us. All of these are subjective but an argument about classes as considered from a per language implementation basis:
Inheritance from multiple sources (interfaces and superclasses, or multiple inheritance). Classes
Access privileges: namely a distinction of protect and private, friendly and not friendly
Shared privileges: an ability to access private data of an instance of the same Class
Javascript does not provide these.

This

The 'this' keyword in JS is something that is not derived from scope nor prototype. It is determined from how the function was called. It can be changed on any function invocation by using foo.call(newthis,...) or foo.apply(newthis,...). If you wish to hold on to your reference (generally in a constructor) save the value of this to a variable (var self = this). The this keyword is set with the following rules:

if calling the property of an object after using lookup (.) it is the object before the lookup operator
if calling without any lookup it is the global object
if calling with .call or .apply it is the first argument of those functions

The value of this cannot be determined at any time except during the new operator, however, your function may not be using the new operator and may then be pointing at another object.

RingoJS and Node.js

2010-09-08T10:47:00.000-07:00

RingoJS is an alternative to Node.js which has some promise. In this post I would like to compare what I consider the strengths of both and weaknesses of both. After that we can explain them in more depth.

Weaknesses:

Node.js

You may not have compile privileges for some C++ addons
Node on Windows is tricky to deal with (though other operating systems are gaining some support with palm adding Node.js to its phones, Joyent running on solaris [no.de])
Non-block style coding, flow of control can be unfamiliar to people used to synchronous or thread based programming
Lack of legacy support, modules for XYZ may not exist
Fast moving changes, most people are sticking to HEAD

RingoJS

Java running Javascript is slower than on C/C++
Lack of use of Javascript's strengths in its api
High level api doesn't resemble coding style of browser
Addons aren't really documented

Strengths:

Node.js

Asynchronous api allows evented programming like in a browser
Single threaded means avoidance of many synchronization issues
V8 is fast and the api is clean (google v8.h if you need help, almost always has the answer)
C++ addons mean you can do almost anything with them
API uses callbacks which exploits Javascript's closures to make your life easier
Low level api allows complex features to occur with relative ease compared to most apis
Evented systems scale stupid well compared to threaded (context change + memory overhead + locking, i wont go into more detail if you comment)
File descriptor passing is AMAZING

RingoJS

Java addons! You can reuse all that old code
JS 1.8 features let you do more scripting goodness
Can run multiple instances inside a single process (you can in v8, but its so hard lets just say you can't)
Synchronous code means you don't have to figure out callbacks when debugging
Asynchronous javascript code can block if needed using sync()
It runs on the JVM, aka, Google App Engine, your grandmothers computer, your phone, anything?
Database support through Java, supported, tested, niiiiice~
Desktop applications have a GUI/Multimedia/Input library to pull from Java
Follows all the CommonJS stuff which is well argued about (I personally think that API is terrible when you could be using language features *first class functions / closures*)

Explanation

Coding Style

Coroutines and Synchronous programming encourage what I like to call "block coding". People are going to be upset on both sides for this argument. Block coding (aka coding w/o first class functions) is a tradition. It has an advantage that it has been done forever by most coders. It has the disadvantage that it doesn't work well with events and it tends to lead to walls of text because there is no need to separate out logic for what should happen after x, because y is just after x, always. Some people are trying to bring coroutines to v8 and as such this is applicable to both.

This comes with terrible and brilliant things (all of these are both good and bad).

The code can just be scanned without knowing whats going on behind the scenes and you know when things happened on a timeline.
You dont need to separate out logic for when things happen
Threads must be synchronized if multiple flows of control exist for your program
Most systems encouraging this lock up all things that can cause synchronization issues

Legacy

Java libraries cover vast regions of problems, and the standard library is vast as it is. Your team probably has java doing something somewhere. C libraries can be hooked into node with relative ease if you use that ABI instead.

Addons

I bring this up because, Javascript can do a lot, but you need to be able to extend it sometimes. Java addons run inside of a VM which is nice and safe, while C++ lets you work with low level and even more libraries (the JNI can work around this from both sides so its a non-issue). Node encourages addons, while I couldn't find too much documentation on the proper way to deal with RingoJS (I assume its the same as with Rhino, but something would be nice).

Flash Bridged Web Sockets in Node

2010-07-25T10:50:00.000-07:00

Many people are talking about how to use websockets and where they are supported. Luckily we can use a Flash substitute in cased that they are not natively in Javascript. In this post I will create a small example of using this fallback technique. Our example will be a simple publish/submission chat.

For the example we are going to create we will need a few things:

node >= 0.1.100
http://github.com/gimite/web-socket-js
http://github.com/miksago/node-websocket-server (npm websocket-server)
http://github.com/senchalabs/Connect/ (npm connect)
a port to serve files on (8000 in our example)
port 843 on the server

Note:

Flash websockets will not be active until the SWF is loaded, either wait for an onload or test other ways to see if the WebSocket interface is ready.
IE 64-bit does not support Flash as of the time of this post.

Websocket Client:

web-socket-js has a sample.html file which will serve as our example of a simple publication/subscription service client. It requires WebSocketMain.swf , swfobject.js , web_socket.js , and FABridge.js . All the browser will have to do to get to this is direct to this page from HTTP:// (Flash Sockets will not work on FILE://)

The only modifications to this file that we need to do are where the WebSocket(url) is going.

If you move WebSocketMain.swf be sure to set WEB_SOCKET_SWF_LOCATION
You can remove WEB_SOCKET_DEBUG if you do not want messages in your console

Websocket Server:

Our server needs to do 3 things:

Serve the files we want to make up our client
Accept websocket connections
Serve a policy file using TCP (Not HTTP://!)

To see all of these in action download:

http://github.com/nodejsbot/flash-websocket-example