Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://webreflection.blogspot.com/2009/02/on-javascript-inheritance-performance.html below:

On JavaScript Inheritance Performance and Libraries Troubles

Please do not get me wrong. I have no intention to say that one or any of cited framework, piece of code, library, is not good or fast enough to extend other classes. This post is about maniac optimization based on personal considerations over some deeper analysis to complete in a way the first benchmark.

I am not criticizing libraries, they are great and they offer everything, I am simply showing a specific case, which is particular on purpose, and a specific behavior that, useful or not, could not be respected.

Few days ago Ajaxian published a post about

via common libraries strategies.

I think the argument is extremely interesting but there's not enough material yet, so here I am with my contribution plus a "best option" proposal.

• libraries (should) manage properly the prototypal chain


• libraries (should) make code more elegant/readable


• libraries (should) let us create overrides being able to call parent/super method implicitly if necessary


• libraries are often based over a generic extended "class" or hierarchy and users should be familiar with that way to extend or create classes in order to avoid internal conflicts

• we are performances or bytes maniacs and we are scared by library obtrusive implementations


• we don't trust the library pattern/strategy to extend function - we know a better way to do it simply and quickly


• we would like to create hybrids unmanageable via used library

About above points, let me answer to this question:

"

" Considering the YUI approach out of the game,

There is a parent class with a toString and a toLocaleString prototype method.

These methods are particular since they are

methods (read: native) and browsers like Internet Explorer do not discover hidden methods even if those have been explicitly assigned.

The extended class should be able to understand the inheritance without problems and produce the expected result, showed in the Ad Hoc example.

• Concept: manual inheritance over usable constructors.


• Troubles: requires a bit of skill and parent calls are always explicit.

// manual implementation
// best performances and expected behavior in every browser
function AdHocClass(name){
    this.name = name;
};
AdHocClass.prototype.toString = function(){
    return this.name;
};
AdHocClass.prototype.toLocaleString = function(){
    return "locale: " + this.toString();
};
function AdHocSub(name, age){
    AdHocClass.call(this, name);
    this.age = age;
};
AdHocSub.prototype = new AdHocClass;
AdHocSub.prototype.constructor = AdHocSub;
AdHocSub.prototype.toString = function(){
    return AdHocClass.prototype.toString.call(this) + ": " + this.age;
};
// This is the expected result We would like to obtain

var me = new AdHocSub("Andrea", 30);
alert(me);                   // Andrea: 30
alert(me.toLocaleString());  // locale: Andrea: 30

• Concept: runtime injected parent (called via base) over explicit initialization via init method


• Troubles: every instance calls two functions when initialized: the contructor plus the init method. This slows down performances. At the same time, not every method is inherited properly.

var BaseClass = base2.Base.extend({
    constructor:function(name){
        this.name = name
    },
    toString:function(){
        return this.name;
    },
    toLocaleString:function(){return "locale: " + this.toString()}
});
var BaseSub = BaseClass.extend({
    constructor:function(name, age){
        this.base(name);
        this.age = age;
    },
    toString:function(){
        return this.base() + ": " + this.age;
    }
});
var me = new BaseSub("Andrea", 30);
alert(me);                   // Andrea: 30
alert(me.toLocaleString());  // ERROR: same as toString both IE and Others

• Concept: lazy dependencies resolution via the initializer method


• Troubles: the initializer method is not that linear and it is probably the slowest in the list. Sometimes we need to call explicitly the method, as first argument, while sometimes we need to modify the arguments object or create an array to call the parent method. I am not sure I used dojo best practices to replicate the scenario but that's what I found googling for a while (Update: thanks to Eugene Lazutkin I could use a better practice which improved consistently performances). Is the rest fine? Not really, Internet Explorer does not inherit some hidden method. Update: apparently dojo offers different possibilities to extend and "play" with parents, so this is just one of them.

dojo.declare("dojoClass", null, {
    constructor:function(name){
        this.name = name;
    },
    toString:function(){
        return this.name;
    },
    toLocaleString:function(){return "locale: " + this.toString()}
});
dojo.declare("dojoSub", dojoClass, {
    constructor:function(name, age){
        this.age = age;
    },
    toString:function($super){
        return this.inherited("toString", arguments) + ": " + this.age;
    }
});
var me = new dojoSub("Andrea", 30);
alert(me);                  // Andrea: 30 - not in IE
alert(me.toLocaleString()); // ERROR: same as toString in IE

• Concept: basically the same one used by base2


• Troubles: even worse than base2 since there are no explicit searches for toString and valueOf (most common hidden methods)

var ResigClass = jClass.extend({
    init:function(name){
        this.name = name;
    },
    toString:function(){
        return this.name;
    },
    toLocaleString:function(){return "locale: " + this.toString()}
});
var ResigSub = ResigClass.extend({
    init:function(name, age){
        this._super(name);
        this.age = age;
    },
    toString:function(){
        return this._super() + ": " + this.age;
    }
});
var me = new ResigSub("Andrea", 30);
alert(me);                   // Error: [object Object] in IE
alert(me.toLocaleString());  // Error: [object Object] in IE

• Concept: runtime injected parent, similar to base2. In my opinion the most clean and elegant way to extend a class.


• Troubles: Classes are created via Class constructor so we have same bottleneck spotted in base2. Inheritance problems are basically the same found in base2: some hidden method is not inherited.

var MooToolsClass = new Class({
    initialize: function(name){
        this.name = name;
    },
    toString:function(){
        return this.name;
    },
    toLocaleString:function(){return "locale: " + this.toString()}
});
var MooToolsSub = new Class({
    Extends:MooToolsClass,
    initialize:function(name, age){
        this.parent(name);
        this.age = age;
    },
    toString:function($super){
        return this.parent() + ": " + this.age;
    }
});
var me = new MooToolsSub("Andrea", 30);
alert(me);                  // Andrea: 30 - not inherited in IE
alert(me.toLocaleString()); // ERROR: locale: Andrea in IE

• Concept: $super variable as parent sent as first argument, imho the most obtrusive way so far and not elegant/intuitive at all.


• Troubles: something works as expected, but only toString and valueOf, as is for base2, are considered hidden methods. The extra argument and the method overload make this library almost slow as dojo inheritance implementation is.

var ProtoClass = Class.create({
    initialize:function(name){
        this.name = name;
    },
    toString:function(){
        return this.name;
    },
    toLocaleString:function(){return "locale: " + this.toString()}
});
var ProtoSub = Class.create(ProtoClass, {
    initialize:function($super, name, age){
        $super(name);
        this.age = age;
    },
    toString:function($super){
        return $super() + ": " + this.age;
    }
});
var me = new ProtoSub("Andrea", 30);
alert(me);                   // Andrea: 30
alert(me.toLocaleString());  // ERROR: same as toString in IE

• Concept: a constructor link to its parent prototype via "this.constructor.superclass". No runtime operations, no injected overloads, just "raw methods" based on explicit calls.


• Troubles: not really. The YUI approach is extremely simple and efficient then "of course it works"!. There are just a couple of steps resolved via YAHOO.lang.extend: the correct constructor reassignment after the prototype one, plus the superclass link. I have just a comment about YUI implementation: guys, why do not you avoid that function creation for each extend call?

    // No var F = function(){}, i SUGGESTION
    extend: function(F){
        return function(subc, superc, overrides) {
            if (!superc||!subc) {
                throw new Error("extend failed, please check that " +
                                "all dependencies are included.");
            }
            F.prototype=superc.prototype;
            subc.prototype=new F;
            subc.prototype.constructor=subc;
            subc.superclass=superc.prototype;
            if (superc.prototype.constructor == OP.constructor) {
                superc.prototype.constructor=superc;
            }
                    if (overrides) {

                for (var i in overrides) {
                    if (L.hasOwnProperty(overrides, i)) {
                        subc.prototype[i]=overrides[i];
                    }
                }
                L._IEEnumFix(subc.prototype, overrides);

            }
                    }

    }(function(){}),

And here we are with the scenario:

function YUIClass(name){
    this.name = name;
};
YUIClass.prototype.toString = function(){
    return this.name;
};
YUIClass.prototype.toLocaleString = function(){
    return "locale: " + this.toString();
};
function YUISub(name, age){
    this.constructor.superclass.constructor.call(this, name);
    this.age = age;
};
YAHOO.lang.extend(YUISub, YUIClass); 
YUISub.prototype.toString = function(){
    return this.constructor.superclass.toString.call(this) + ": " + this.age;
};
var me = new YUISub("Andrea", 30);
alert(me);                   // Andrea: 30
alert(me.toLocaleString());  // locale: Andrea: 30

These are my considerations:

• The fastest way to use a parent method is an explicit call


• The best way to perform above step is via a link able to remove explicit dependencies (read: MyParentClassName instead of this.constructor.superclass). In this way methods could be easily transported from a prototype to another one without problems (less memory usage and less code to maintain)


• The this.parent() solution is the cleanest one and generally speaking more close to our concept of "Object Oriented JavaScript". It is portable, it is meaningful, it is shorter than an explicit call with or without a link but it is not that fast to execute.


• Using best practices to cache all we need, create a quick wrapper, resolving hidden methods problems, will not bring us to native or YUI performances, but at least in a good scenario: fast enough to guarantee performances over code elegance and readability

So here we are with my proposal:

• Concept: parent in prototype but changed runtime for hierarchy purpose only if necessary (read: only for overrides). This will allows us to call parent directly in the constructor, as example, so we won't have double calls for each instance. At the same time, this implementation lets us call explicitly a parent method from those whose were not inherited.


• Troubles: performances are the best but still far from native one.

function WRClass(name){
    this.name = name;
};
WRClass.prototype.toString = function(){
    return this.name;
};
WRClass.prototype.toLocaleString = function(){
    return "locale: " + this.toString();
};
function WRSub(name, age){
    this.parent(name);
    this.age = age;
};
wr.extend(WRSub, WRClass, {
    toString:function(){
        return this.parent() + ": " + this.age;
    }
});
var me = new WRSub("Andrea", 30);
alert(me);                   // Andrea: 30
alert(me.toLocaleString());  // locale: Andrea: 30
// last, but not least

WRSub.prototype.explicitParentToString = function(){
    return this.parent.prototype.toString.call(this);
    // instead of
    return this.constructor.superclass.toString.call(this);
};
alert(me.explicitParentToString()); // Andrea

var wr = {
    extend:function(parent, extend){
        /**
         * (C) Andrea Giamamrchi
         * Mit Style License
         */
        return function(self, Function, Object){
            var prototype = function(){
                this.prototype[key] = 
                    this.prototype.parent && typeof Object[key] == "function" && typeof this.prototype[key] == "function" ?
                        extend(Function, this.prototype[key], Object[key]) :
                        Object[key]
                ;
            };
            if(Object){
                parent.prototype = Function.prototype;
                self.prototype = new parent;
                self.prototype.constructor = self;
                self.prototype.parent = Function.prototype.parent ?
                    extend(Function, Function.prototype.parent, Function) : Function
            } else
                Object = Function;
            for(var key in Object)
                prototype.call(self);
            for(key in {toString:key})
                return self;
            //* ... for Internet Explorer only ...
            for(var
                split = "hasOwnProperty.isPrototypeOf.propertyIsEnumerable.toLocaleString.toString.valueOf".split(".");
                key = split.shift();
            )
                if(Object.hasOwnProperty(key))
                    prototype.call(self);
            //*/
            return self
        }
    }(
        function(){},
        function(parent, extend, Function){
            return function(){
                this.parent = extend;
                var result = Function.apply(this, arguments);
                this.parent = parent;
                return result
            }
        }
    )
};

Something to consider before you try the benchmark page ... I removed the purposeless direct method call since it is absolutely the same for every basic class, created via library or not.

The order is by performances, where generally speaking are these:

1. Ad Hoc Manual Explicit Inheritance


2. YUI lang.extend (close to Ad Hoc)


3. wr.extend - WebReflection proposal (closer to jClass than YUI)


4. jClass (truly close to base2)


5. base2 (truly close to jClass)


6. dojo


7. Prototype


8. MooTools

And have a nice week end ;-)

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4