Konstruktor-Closure vs. Prototyp

[jobo]

Hallo,

Deshalb muss man sich bei wirklich Geschwindigkeitsrelevanten Anwendungsfällen überlegen, ob man nicht lieber auf die strenge Kapselung verzichtet und eine durch Namenskonvention pseudo private Variabel verwendet, da dies deutlich schneller ist.

Ich weiß nicht, ob ich es nicht schon hier im Thread verlinkt habe:
http://www.aminutewithbrendan.com/pages/20110216

Brendan Eich meint, dass sich die JS-Programmierer darüber nicht unnötig den Kopf zerbrechen sollten und es mehr die Aufgabe der JS-Engine-Entwickler sei, das so zu optimieren, dass sich letztlich nur noch wenige Unterschiede ergeben.
Das heißt natürlich nicht, dass das Prototype-Pattern derzeit nicht schneller ist. Aber aus bloßer Angst auf Kapselung zu verzichten hält er für »Premature Optimization«. Er plädiert daher für Kapselung, wenn es einem hilft. Wenn sich das im Nachhinein beim Profiling als signifikante Performance-Bremse herausstellt, kann man immer noch optimieren und ggf. zur Prototyp-Lösung wechseln.

Um das Beispiel geht es ja:

  
// Are these two patterns the same performance/memory-wise  
  
function MyConstructor() {  
    function someMethod() {  
        console.log('foo');  
    }  
}  
var instanceA = new MyConstructor();  
  
function OtherConstructor() {}  
OtherConstructor.prototype = {  
    someMethod: function () {  
        console.log('foo');  
    }  
}  
var instanceB = new OtherConstructor();  

Logisch scheint ja, dass bei häufigem Aufruf von MyConstructor immer wieder die Methode mit definiert wird. Statt dass sich viele von MyConstructor abgeleitete Objekte auf _eine_ Prototyp.Methode beziehen. Wobei die Frage vielleicht erlaubt ist, wer denn so viele Objekt(instanzen) braucht.

Die Prototypkette ist nur beim ersten Aufruf etwas lahmer, weil anschließen gecached wird. Wenn ich das jetzt richtig rausgehört habe.

Gruß

jobo