Prototype vs Module pattern performance (v135)

Revision 135 of this benchmark created on

Description

Removed iterations in tests, because jsperf already does that for us. And renamed variables to be more meaningful to us humans. And other cosmetic changes.

The most important thing to remember is to use the right tool for the job. All these tests do is reference an object with a complex memory allocation. When you don't need something fancy, you're better off using a regular old object

Setup

function TraditionalPrototypeClass() {
    }
    TraditionalPrototypeClass.prototype.foo = function() {
    };
    TraditionalPrototypeClass.prototype.bar = function() {
    };
    
    var o1 = new TraditionalPrototypeClass();
    
    function Constructor() {
        this.foo = function() {
        };
        
        this.bar = function() {
        };
    }
    var o2 = new Constructor();
    
    var o6 = (function () {    
        return {
            foo: function () {},
            bar: function () {}
        }
    })();
    
    var o3 = (function () {
        var foo = function () {};    
        var bar = function () {};
        
        return {
            foo: foo,
            bar: bar
        }
    })();
    
    var standardObject = {
        foo: function(){
        },
        bar: function(){
        }
    };
    var o4 = standardObject;
    
    var o5 = {
        foo: function(){
        },
        bar: function(){
        }
    };

Test runner

Ready to run.

Testing in
TestOps/sec
Prototypal
o1.bar;
o1.foo;
ready
Constructor
o2.bar;
o2.foo;
ready
Revealing Module pattern (cached functions)
o3.bar;
o3.foo;
ready
Use the right tool for the job
o4.bar;
o4.foo;
ready
Use the right tool for the job 2
o5.bar;
o5.foo;
ready
module pattern
o6.bar;
o6.foo;
ready

Revisions

You can edit these tests or add more tests to this page by appending /edit to the URL.