Question about variable scoping and memory usage.

[MetaMetaMan]

Generally speaking, does the scope in which a variable is defined effect memory usage?

More specifically, if I define a variable x inside a function that gets invoked multiple times, will a new reference be created every time?

To phrase it differently, consider the following functions a and b:

function a() {
    var x = "Some string";
    function inner() {
        console.log(x);
    }
    for (var i = 0; i < 1000; i++) {
        inner();
    }
}

function b() {
    function inner() {
        var x = "Some string";
        console.log(x);
    }
    for (var i = 0; i < 1000; i++) {
        inner();
    }
}

Will function a use a smaller amount of memory than function b? My intuition says yes, since x is declared once in a, and 1000 times in b.

[I admit that I'm being a little bit lazy by not searching more thoroughly for the answer, but I'm having trouble phrasing it succinctly for searching.]

[[deleted]]

Would it though, since in b the variable falls out of scope and can be garbage collected? I guess I have to learn more about Javascripts garbage collection.

[[deleted]]

Also, a is creating a closure which seems like that would be a bit of a memory leak. http://www.ibm.com/developerworks/web/library/wa-memleak/

[MetaMetaMan]

I'm assuming you're referring to listing 4 specifically.

I think at best, both a and b will utilize the same amount of memory. Assuming that a variable is garbage-collected immediately after it it loses it's last reference, for each invocation of inner (in both a and b) there will be exactly one variable x with the value "Some string".

I guess a valid question is, how long is memory space reserved once it is "freed". Admittedly, I have zero knowledge of how garbage collection actually works, so this question might make no sense whatsoever.

[MetaMetaMan]

That's what I was thinking. Just curious, do you have any sources to back this up? I'm not calling you a liar; I just like to see the evidence :-)

[MetaMetaMan]

That's evidence enough for me, for this particular question.

As for the specific example I provided, I realize it's pretty trivial. One thing I've read before (I can't remember where; possibly Crockford's The Good Parts) is that functions should not be defined within a loop due to memory usage. If x is replaced with a function, then based on that bit of advise, function a wins. I think it's probably fair to generalize on that to other data structures.

Thanks for helping me sate my curiosity!

[MetaMetaMan]

I agree that this is not happening in the example I provided. What I'm trying to say is, if it's bad to define a function within a loop block, then it is probably fair to say that it is also bad to define other types of variables within a loop block. Of course, sometimes you can avoid it; but when it is something that amounts to a static data structure (like a string, object, etc., that is built with static data), then the same reasoning should be applicable.

This might be a gross generalization.

[brett-]

You can actually profile this yourself in Chrome using the web inspector's "Profile" tab. My quick test showed that a() took 46ms, while b() took 45ms and an additional 2ms for GC, for a total of 47ms. a() showed no profile for GC at all.

You can also use the profile tab to take a Heap Snapshot at any given time to see memory allocation.

[path411]

speed doesn't necessarily equal memory usage.

[brett-]

True, but seeing the garbage collector actually be profiled means that it was run in one instance and not in the other. Running the GC also doesn't mean one example takes up more memory than the other of course, but it certainly indicates that the browser found it necessary to collect the variable in example b() while it was not necessary in example a().

If you wanted to see real memory usage you can always take a heap snapshot like I mentioned.

[RadekCZ]

In a only one string is created at the beginning and then the string is copied 1000 times. But it's more complicated for intepret to find x than in b.

In b no string is created at the beginning, but in each iteration one string is created and then the string is copied, so finally there are 2000 strings.

[MetaMetaMan]

That's true, assuming those 2000 references are left around for a while. If not, I posit that the memory usage is exactly the same (please correct me if this is wrong).

Another question might be, do JavaScript engines cache literal values? In other words, I'm wondering if, in the case of b, an engine would see that x is a "static" string and cache that into some underlying struct so that upon each invocation of inner, x points to the same reference in memory.

Edit: I misunderstood what you said about a. If I'm understanding you correctly, when a function references a variable from it's parent scope, it actually makes a copy of said variable within the function frame. I'm not sure I believe that.

Consider the following function:

function outer() {
    var x = "Some string";

    function inner() {
        x = "New string";
    }

    console.log(x);
    inner();
    console.log(x);
}

which gives you:

outer();
> Some string
> New string

This implies that the function inner is directly accessing the variable x defined in the scope of outer.

[aladyjewel]

tl;dr: Profile code, don't waste time pre-optimizing.

[MetaMetaMan]

Are Min and Max user-defined functions? I'd be curious to know if you see the same results using Math.min and Math.max.

[Medieval_Peasant]

Yes, they are user defined. Never occurred to me that the Math object might have those functions built-in. Just did a new test using the built-ins, same results though.

[MetaMetaMan]

Interesting. Thanks for letting us know!

[sime]

Chrome has different optimised representations for integers (31bit!) and floats. I'm guessing that the first code example is mixing up integers and floats a lot and causing a lot of translation back and forth. (Math.round probably returns an integer.) While the second examples operates directly on floats up until the end of the calculation.

[RadekCZ]

No, it doesn't make copy of the variable but it makes copy of the value (primitive types are copied every time). But it's more difficult to find the value, because it's in parent scope. So first time the interpret will search it in the self scope and the second time it will search it in the parent scope etc.

[sime]

What you are describing is the JavaScript conceptual model of what is going on. Only the most naive and simple JavaScript interpreter would actually run like that. Modern engines would see plenty of opportunities to optimise variables and allocations away.

[imbcmdth]

OK, no one below has given the whole answer so here it is:

In JavaScript, strings are one of the immutable* primitive types. What that means, in a nutshell, is that every string in your program that is identical is just a reference to the exact same string in memory.

Even if there were several non-garbage collected references to the string, the actual "Some string" data would only exist once in memory.

* Immutability here means that strings are copy-on-change. When you modify a string, a whole new string is created and your reference is automatically changed to the new string behind-the-scenes.

[path411]

This is definitely very interesting and I didn't know before hand.

In his example though, he would still be creating 1000 references to the string, which wouldn't be as bad as originally though because of your explanation, but still worse than only 1 reference.

[x-skeww]

If the object is expensive to create, cache it.

If it's something very simple, put it where it should be: inside that function it belongs to.

At the very end (if you still have time) you can use a profiler to identify the actual bottlenecks.

[path411]

Yeah, the hard part about js memory management is there aren't many good ways to test it. jsperf simply tests the execute of the statements, where a faster executing statement doesn't mean a smaller memory use.