views:

114

answers:

4

I'm working on a bit of code where I'm attempting to hide some private variables inside closures. The thing is the environment is fairly constrained in terms of memory, so I'm also concerned with keeping the overall footprint of the classes low.

What is the impact of using closures to hide private instance variables and methods when compared to just making all methods and variables on an object public? Would an instance of the one using closures take up more memory than an instance that did not use closures? If so, how much more memory would I expect to use?

my code would look like this

function Foo() {
   // private variables
   var status = 3;
   var id = 4;
... 
...

   // private methods
   var privateMethod = function () {
      // do something awesome
   }
   ...

   // a whole bunch of these


   // public methods

   this.publicDriver =  function () {
        privateMethod();
   }
    .. a few more of these

};

Versus

function Bar() {
   // only define public variables
   this.x = 1;
   this.y = 3;
}

Bar.prototype.method1 = function () { 
// blah;
}

.... Going on and defining all the rest of the methods.

A: 

The following link shows information about some tips for profiling javascript functions to see information about their performance:

http://ejohn.org/blog/function-call-profiling/

REA_ANDREW
A: 

Check out these benchmarks. Although they are inheritance benchmarks, it should give you an idea of the memory impact since some of them uses closures, and some don't.

Pablo Cabrera
+1  A: 

Okay, so from what I can see, constructing the class using the closure case constructs new function objects for each method defined within the constructor, while the prototype assignment way creates a central function that is shared by all instances of the objects. The central instance is then interpreted per object for the proper instance variable references.

I'm guessing each function defined in the closure example refers back to the same stack frame.

Still, in my case, it's a lot more objects floating about.

Gopherkhan
Just actually read a bit in the "High Performance Javascript" book that confirms this.
Gopherkhan
A: 

The fact that variables enclosed in a closure can be updated from outside the closure in JavaScript, would suggest that there only ever exists one copy of the variable. Which means that there's no reason why there should be any significant memory impact of using closures in JavaScript.

If the values of the variables were frozen once the closure was created, that would be a different story since it would mean that each closure would have to have a private copy of its enclosed variables.

All that being said, you should still perform the actual benchmarks to check :-)

KaptajnKold
Unfortunately, I believe these comments are incorrect (well, except for the one about doing benchmarks to check :-). The "closure" variables remain in the stack frame, if you will, of the *call* of the function, and can only be manipulated by functions that were created in the same call, and made available somehow outside the closure. In Gopherkhan's Foo() constructor, if he calls "f1 = new Foo(); f2 = new Foo()" and Foo defines methods that can modify and access the "status" closure variable, he'll be able to see that the values diverge between the two objects.
BobS
I think you are misunderstanding me. Consider this: function Baz() {var p = 42; this.setP = function(q) {p=q;};this.getP = function(){return p;}}. In some languages, getP() will always return 42, even if setP ha been called with another value. That is because getP will make a copy of p when it is created, and that copy will not be updated when p is updated in the outer scope. That is not the case in JavaScript, though: p in getP refers to the same p as in setP, and thus can be updated.
KaptajnKold