3 Answers
3

The lowest memory use of your three options would be to use the context variables (idea #3), since it eliminates duplication. The other two copy the values to a second object created inside of that function. Here's the background:

Everything in JavaScript is an object and objects are internally just hashmaps relating string keys to a reference to its actual value. This includes ordinary local variables; internally they're properties on an invisible context object that can be accessed by that function and any functions defined inside of it. Using $.extend vs assigning properties directly makes no difference, because the extend function is just syntactic sugar around a for loop that copies properties from one object to another.

Since a function's context (local variable) object is retained for use by all functions defined inside of it, the lowest memory usage of your options would be the one that doesn't duplicate it to new internal objects. But the difference would be minor.

If you really want to cut your memory usage to the smallest level and write easier-to-maintain code, I'd suggest getting rid of the fancy (and hard-to-debug) context wrapping and code it the old fashioned JavaScript OOP way: use an ordinary constructor defined either at the top level or inside a single wrapper function that's run only once when the page is first loaded. That gets rid of the duplicate contexts. Call it with the 'new' keyword and pass in data as arguments that you assign to 'this'. Do your initialization inside of the constructor, and nothing more.

Put all of your method functions on its prototype and then use it as a normal, ordinary, no-frills JavaScript object.

Great answer, exactly what I was looking for. Regarding the last part, this "design" is required because I'm using RequireJs (hence the root function) and Backbone (hence the extend, replaced by jQuery here for a more broader approach).
– Cyril N.Apr 11 '13 at 7:19

If you're using a RequireJS module as a constructor that gets called every time you need a new object, then that style makes sense. It's also the worst memory-wise since you now have duplicate prototypes defined on each child object. (In normal JavaScript OOP the shared prototype is defined once and child objects contain only the properties they change plus a single reference to their prototype.) Usually I see people define the constructor and prototype in the module and return that, and then get back to the normal OOP way in the rest of their code.
– Richard ConnamacherApr 11 '13 at 14:52

I did that for my shared prototype (like the same functions used in the "list" pages or "details" page, and I extend this prototype with specific functions for any list or details).
– Cyril N.Apr 11 '13 at 17:38

I use $.extend because I recreate a similar environment as Backbone does when you instantiate a Backbone Object. My question here is specifically oriented about the difference of the memory usage in those 3 use case, I know it's different from the DOM-elements memory leaks, but that's not the point of the question.
– Cyril N.Apr 8 '13 at 15:01

If you don't need them outside of the scope of the function, then use normal variables.

If you need them outside of the scope of the function, then put them on the constructor.

Instance variables (that change with each instance)

For properties that you know will have different values for each instance, declare them with the proper type in the constructor so that they can be optimized into the static type associated with the constructor.

For properties that are shared among all objects (like methods), use the prototype.

For properties that will more likely keep their default value, if you want speed of access, you should declare them in the constructor, but if you want to use far less memory, you should put the default values on the constructor and only add a property to the object if it differs from the default value.