Sunday, January 16, 2011

JavaScript Performance: Creational Patterns

Which JavaScript creational pattern is the most efficient? Is it an object literal, functional, or pseudoclassical object? With JsTestDriver, I setup a quick performance test to gather the metrics.


Creational Patterns to Test

I tested the three most popular creational patterns in JavaScript. Object literals, functional objects, and pseudoclassical objects. In particular, I wanted to test their singleton and instance based execution times.
/*
* Pseudoclassical object designed as a singleton
*/

var PseudoclassicalSingleton = new function(){
this.getName = function(){
return 'Pseudoclassical';
};
};

/*
* Functional object designed as a singleton
*/

var FunctionalSingleton = (function(){
return {
getName: function(){
return 'Functional';
}
};
})();

/*
* Object literal (implicitly singleton)
*/

var ObjectLiteralSingleton = {
getName: function(){
return 'ObjectLiteral';
}
};

/*
* Pseudoclassical object designed as a non-singleton
*/

var PseudoclassicalInstance = function(){
this.getName = function(){
return 'Pseudoclassical';
};
};

/*
* Functional object designed as a non-singleton
*/

var FunctionalInstance = function(){
return {
getName: function(){
return 'Functional';
}
};
};


Performance Test Runner

I setup JsTestDriver to execute the test cases against Firefox. One advantage of JsTestDriver is I can run my test cases against any browser! Each performance test will instantiate its creational pattern 1.4 million times as indicated by the RUN_TIMES constant. Additionally, I ran the performance test suite twenty times to gather an adequate average.
CreationalPatternsPerformanceTest = TestCase("CreationalPatternsPerformanceTest");

var RUN_TIMES = 1400000;

var performanceTest = function(name, f){
console.time(name);
for (var i = 0; i < RUN_TIMES; i++){
f();
}
console.timeEnd(name);
};

CreationalPatternsPerformanceTest.prototype.testResponseTimes = function(){
performanceTest("ObjectLiteral (singleton)", function(){
ObjectLiteralSingleton.getName();
});
performanceTest("Pseudoclassical (singleton)", function(){
PseudoclassicalSingleton.getName();
});
performanceTest("Functional (singleton)", function(){
FunctionalSingleton.getName();
});
performanceTest("Pseudoclassical (instance)", function(){
new PseudoclassicalInstance().getName();
});
performanceTest("Functional (instance)", function(){
FunctionalInstance().getName();
});
};



Performance Test Results
 Object Literal (singleton)Pseudoclassical (singleton)Functional (singleton)Pseudoclassical (instance)Functional (instance)
Avg (ms)10931095109433013341
Min (ms)10701064106232253246
Max (ms)11121114111334603476



Areas of Interest


I had three specific comparisons I wanted to evaluate heading into this experiment:
  1. Object literals vs the others (functional and pseudoclassical): I knew object literals were going to be the most efficient. However, I really wanted to see how much faster they really are. The result was surprising. Object literals (1093 ms) barely out performed functional (1094 ms) and pseudoclassical (1095 ms) response times. This difference is really negligible. Unlike object literals, functional and pseudoclassical objects can provide security. And the performance degradation is almost non-existent.
  2. Functional vs Pseudoclassical: There are always debates over these two objects. While I personally prefer pseudoclassical objects when security is a concern I definitely wanted to see which one was the more performant option. In the end, neither pattern distanced itself from the other in regards to performance.
  3. Singletons vs Instance based Objects: I knew singletons would be the most efficient. However, I wanted to see what this difference really was. On average, singletons were three times faster.


Lessons Learned

  1. Prefer singletons over instance based objects when possible.
  2. Prefer object literals when you are not concerned about privacy.
  3. The performance metrics alone are not enough to sway the functional vs pseudoclassical debate.

Sunday, January 2, 2011

JavaScript: Securing Pseudoclassical Objects

Which JavaScript pattern do you prefer for object creation? Functional or pseudoclassical? This question makes for a very interesting debate. The first time I read JavaScript: The Good Parts I was sold on the functional pattern based upon the knowledge that it was the only pattern that supported privacy. However, the pseudoclassical pattern can be secured! Based upon the fact that pseudoclassical objects can be secured and its many additional advantages make it the ideal choice for object creation.


Securing Pseudoclassical Objects

/**
* Pseudoclassical object with private variables and functions.
*
* @constructor
* @param {string} name
* @param {number} age
*/

var Person = function(name, age) {

/** @public variable */
this.name = name || 'Brad';

/** @private variable */
var age = age || 34;


/** @private function */
function setAge(a) {
age = a;
}

/** @public function with access to private methods and variables (privileged) */
this.getAge = function () {
return age;
};
};


Why is Everything Public?

Security is not often documented within JavaScript books and I rarely see examples where developers secure their JavaScript objects. Typically, everything is exposed publicly. If you develop mobile applications with Titanium or are developing a JavaScript framework you absolutely must apply security with either the functional or pseudoclassical pattern. And of all the Titanium code I have read over the past month not a single example or sample application was concerned about privacy. Training can remedy this problem.


JavaScript Code Completion

auto completeA simple way to quickly view the publicly available methods of an object is with code completion. For example, the Aptana Eclipse plug-in has code completion built-in and works very well for JavaScript development.