JavaScript experts: Do block-scopes with `{}` and anonymous functions both help garbage-collection?

Question

In the book "You don't know JS: scopes & closures", Kyle simpson states that a block-scoped variable helps with garbage collection, here is the specific example:

function process(data) {
// do something interesting
}

{
let someReallyBigData = {};
process(someReallyBigData);
}

var btn = document.getElementById("my_button");
btn.addEventListener("click", function click(evt) {
console.log("Clicked!");    
}, false);

Now the above example is supposed to help with garbage-collection since the variable someReallyBigData will be dropped from memory as soon as the block ends, unlike this example, which doesn't help with garbage-collection:

function process(data) {
// do something interesting
}

var someReallyBigData = {};

process(someReallyBigData);

var btn = document.getElementById("my_button");
btn.addEventListener("click", function click(evt) {
console.log("Clicked!");    
}, false);

Now I am sure this guy is correct about the examples he provided (the first one); however, i am wondering whether or not everything would be the same if we used an anonymous IIFE (Immediately Invoked Function Expression) along with a normal var instead of the {} curly braces and the let variable. Let me turn that into an example:

function process(data) {
// do something interesting
}

(function(){
var someReallyBigData = {};
process(someReallyBigData);
}());

var btn = document.getElementById("my_button");
btn.addEventListener("click", function click(evt) {
console.log("Clicked!");    
}, false);

Looking at it from the surface, they both should do the same thing; since just as the block-scoped someReallyBigData variable could not be accessed anymore by anything after the block of code had executed, the code inside the anonymous function cannot be accessed by anything once it has executed, by anything, from anywhere.

So, do they really have the same effect on the garbage-collection mechanisms of the Javascript engine ? I was almost certain this was the case until I googled "anonymous function garbage-collection" and almost all the material that showed up said only negative things like "anonymous functions cause memory leaks" and etc.

I would be glad if someone could shed some light on this thing.

Please don't forget that my question is a bit specific to the examples I provided, thanks!

Answer 1

(V8 developer here.) Yes, there are several ways to make objects unreachable, including at least all of the following:

• Put stuff in let-declared variables in a block scope
• Put stuff into an IIFE
• Clear the variable (var or let) when you're done with it: someReallyBigData = null;

The end result will be the same in all cases: objects that are no longer reachable are eligible for garbage collection.

Other notes based on the discussion here:

• The advice quoted in the question makes sense for top-level code. Within a reasonably sized function, I wouldn't worry about it -- the function will probably return soon enough that there is no difference, so you don't need to burden yourself with such considerations.

• There's a big difference between "an object can be freed now" and "an object will be freed now". Letting something go out of scope does not cause it to be freed immediately, and does not cause the garbage collector to run more often. It just means that whenever the garbage collector next decides to go looking for garbage, the object in question will be eligible.

• IIFEs are IIFEs regardless of whether they're anonymous or not. Example:

  (function I_have_a_name() {
    var someReallyBigData = ...;
  })();
  // someReallyBigData can be collected now.
  I_have_a_name();  // ReferenceError: I_have_a_name is not defined
  

• Creating closures in and of itself does not keep things alive. However, if closures reference variables in their outer scope, then (of course!) those can't be collected as long as the closure is around. Example:

  var closure = (function() {
    var big_data_1 = ...;
    var big_data_2 = ...;
    return function() { return big_data_1.foo; }
  })();
  // big_data_2 can be collected at this point.
  closure();  // This needs big_data_1.
  // big_data_1 still cannot be collected, closure might need it again.
  closure = null;
  // big_data_1 can be collected now.
  

• The optimizing compiler has little influence on all this. It usually operates on a per-function bases, and usually the top-level is not optimized (because most logic tends to be in functions). Within a function, the optimizing compiler is very well aware of the lifetimes of objects (that's part of what it means to be an optimizing compiler).

Answer 2

JavaScript only has block level scope when you use the let or const keywords in declarations. Just because you have {} alone does not create block-level scope (as is the case in most other languages).

Aside from that, garbage collection is implementation dependent and you would most likely not notice any difference in performance due to block scoping.

Anonymous functions can have an impact on garbage collection because the function can be set up in such a way that it doesn't have to be stored for potential calling later. A good example of this would be a function that needs to run only once (i.e. when the document is fully parsed):

window.addEventListener("DOMContentLoaded", function(){ . . . });

However, that doesn't mean that all anonymous functions provide this benefit because the function could wind up being stored (i.e. if it is returned from a function and then captured in a variable) or if the anonymous function sets up closures, then all bets are off.

Also, be aware that you can't unit test anonymous functions as simply as you can named functions.

Answer 3

I am wondering whether or not everything would be the same if we used an anonymous IIFE

Sure that's possible, it's what transpilers do to emulate block scopes as well. However IIFEs look a bit awkward, block scopes with let/const variables are easier to use. See also Will const and let make the IIFE pattern unnecessary?.

Now the first example is supposed to help with garbage-collection since the variable someReallyBigData will be dropped from memory as soon as the block ends, unlike the second example, which doesn't help with garbage-collection.

Notice that the word is helps, not enables. Today's engines can garbage-collect the variable just fine, as their optimiser sees that it's not used in the preserved closure. The block scope only makes this kind of static analysis easier.