9

What is the impact on running-time and memory defining a clousre vs. global-scope function?

function a(){
      //functions (option A)
}
//functions(option B)

I understand that Option A has the advantage of function-a-scope(Closure)...

lets say that I have 1000 functions, how would that impact both running time and memory?

2 Answers2

8

If you use inner functions, the run time has to allocate and save their contexts for any future invocation, and this happens each time the function containing them gets called. As a result, it is convenient to imagine that declaring an inner function works like constructing an object, whose members are simply the variables in the enclosing scope around that function.

This may not be all that bad if you do it infrequently, since the amount of memory is about the same as allocating an object on the heap; (and there are some clever optimizations you can do to avoid this in some cases, for example if you only pass the function down the call stack you can allocate in the local stack space, or do some inlining etc.). However, in most circumstances it is still an allocation, so you should avoid using too many of them in busy loops or creating many inner functions.

So to answer your question, option B would be faster in general. But don't let this discourage you!

My final take is that the convenience inner functions afford completely outweighs the small run time overhead, and I would say use them wherever convenient. If it turns out to be a performance bottleneck, go back and optimize them out.

Mikola
  • 9,176
  • 2
  • 34
  • 41
  • thanks a lot! is there any known benchmark in that matter? (I prefer a v8 one) –  Jun 25 '11 at 07:47
  • 1
    You could write one yourself, but it isn't going to tell you anything. An inner method that it is never called can be inlined and the allocation can be skipped, much like an object that never escapes stack scope. If you need to tune your code, use chrome's built in profiler and figure out where it is going slow, then optimize that section. Really, don't worry about tuning the performance of inner functions (unless your profiler tells you that they really are what is slowing you down :) ) – Mikola Jun 25 '11 at 07:49
  • 1
    Also the caching trick is very useful. `var a = (function() { function inner() {} return function real() { };)();` – Raynos Jun 25 '11 at 07:54
  • 1
    well one use-case is that I will define about 1000 functions inside a function that get invoked upon every new user(session) <-- this is a node.js usecase.. –  Jun 25 '11 at 08:59
6

Performance

A very tiny benchmark case:

#1 inner function: http://jsfiddle.net/bMHgc/

#2 function outside: http://jsfiddle.net/sAVZn/

At my machine: (5000 * 1000 times)

#1 - 700ms

#2 - 80ms

Memory

They are almost the same ...

I would recommend option A, if possible, since it can make your code cleaner.

Liangliang Zheng
  • 1,763
  • 11
  • 16
  • 1
    Use jsperf for benchmarks. I think option A makes your code cleaner. Also an order of magnitude is not "almost the same" – Raynos Jun 25 '11 at 07:56
  • 2
    those aren't equal test cases. Your first test-case is creating a new function for each iteration, your 2nd is not. –  Jun 25 '11 at 08:12
  • Sorry about the typo, I meant to say 'option A' – Liangliang Zheng Jun 25 '11 at 12:17
  • @cwolves, I can only partially agree with you. If browsingLoops raised the code as var a = (function(){ function b(){} return function(){ b() }}());, I would say the function is only created once. But we are sorta talking about inner-function in this case. – Liangliang Zheng Jun 25 '11 at 12:30
  • 2
    10 years later, I had to modify the codes to 500000*1000 - and both tests run in a similar time of around 1000 ms. – Sinus the Tentacular Jul 06 '21 at 10:36