javascript - Prototypes or closures for execution consistency and performance? -


what best compromise between performant execution , execution time consistency method calling in javascript?

i'm still learning javascript , use prototypes (i.e. brendan eich here) think i'm finding better performance , consistency function closures (i know i'm on optimizing). 1 prototypal pattern i've been testing:

function prototypea() {} prototypea.prototype.a = 0; prototypea.prototype.b = 0; prototypea.prototype.somemath = function() {     this.a += 1;     this.b += 2; }; var test = new prototypea(); test.somemath(); 

decided after reading (great!) post benchmark closures. current closure pattern i'm drifting toward:

var submodule = new((function() {     var = 0;     var b = 0;     var somemath = function() {         += 1;         b += 2;     };     return function() {         this.somemath = somemath     }; })())(); 

i'm finding many benchmarks of various patterns misleading due errors in test setup such calling constructors in benchmark or calling methods in ways cause different scope traversal paths. i'm trying test method execution.

after lots of benchmarking locally (benchmark.js across many different patterns), put notable patterns:

jsperf here

my findings seem support organized closures don't deviate in execution time other types of objects (i use term "type" loosely). realize wrong due number or errors on benchmark or setup.

thanks looking!

since use case animation, want stick closures. simple rule of thumb javascript "the more . there are, slower code goes". in examples posted on jsperf, slowest ones ones referencing this quite bit. every time that, engine has @ current object , determine whether or not trying access available on object, , if has prototype chain. on closure side of things, you're referencing rather limited scope, predetermined function you've written, , engine has able @ scope reference variables in it.

now, there gotcha's. first, usage of this faster when you're referencing once or twice. not case in example, it's worth mentioning. more times add reference this, slower prototype reliant code goes. @ this simple perf example. second, if you're constructing lot of these modules (for example, if you're building data grid), construction incredibly slow closures , there's lot of memory wasted. see this example speed difference. more methods , properties add, worse gets. that's because creating new closure each time makes unique functions , properties, whereas prototype based 1 reuses same stuff.

in either case, humble recommendation @ situation you're programming for. of time, using prototypes way go - readability [in cases], re-usability, extendability.. if they're slow, can't use them. being said, there's nothing wrong combining 2 concepts give reusable , modular setup methods don't hit often. instance, try using 'mixins':

var mixin = {     interval: 100,     finish: function () { window.clearinterval(this.intervalref); },     start: function (callback) { this.intervalref = window.setinterval(callback, this.interval) };  var module = (function () {     function getmessage () {         return "weee!";     }     var somethingthatreallyneedsspeed = function () {         var iterations, self = this;          this.start(function () {             console.log(getmessage());             iterations++;             if(iterations > 10000) {                self.finish();             }         });     }     somethingthatreallyneedsspeed.prototype = mixin;     return somethingthatreallyneedsspeed; })(); 

in example, construction speed isn't hit bad due prototype being set reference mixin object - there 2 methods , property special function not need have constructed each time, still has available via this.

</rant>


Comments

Popular posts from this blog

.htaccess - First slash is removed after domain when entering a webpage in the browser -

Automatically create pages in phpfox -

c# - Farseer ContactListener is not working -