Take the 2-minute tour ×

A while ago I read that you shouldn't use Function.caller inside a function because it makes the function non-inlineable. To test this assertion I wrote the following benchmark:

Does Function.caller affect preformance? · jsPerf.

The results prove that using Function.caller indeed makes a function execute slower than normal:

  1. In Opera it is 16% slower.
  2. In Chrome it is 80% slower.
  3. In Firefox it is 100% slower.

Hence my question is this: what's the concensus on using Function.caller in JavaScript? Is it alright to use it sparingly? Should it be shunned altogether?

share|improve this question
Your "Normal function" function isn't normal in any sense, it references another magical property .name... Fixed benchmark at: jsperf.com/does-function-caller-affect-preformance/2 –  Esailija Aug 15 '13 at 23:14
@Esailija That's something I didn't know. Thank you. –  Aadit M Shah Aug 15 '13 at 23:16
add comment

2 Answers

up vote 2 down vote accepted

As far as I know, dynamically inspecting the execution stack with caller/callee/etc is not allowed in strict mode so you can kind of see that as a consensus to avoid this feature if possible.

Anyway, why do you even want to use Function.caller in the first place? It makes your code depend on something that usually doesnt matter (the call stack) and data gets passed around implicitly instead of via explicit arguments. The only real use I ever saw for this kind of feature is printing stack traces and in that case you usually can pay the performance cost or can get around it with a debugger.

share|improve this answer
I don't want to use it for any production code. Currently I just want to experiment with it and see what I can do. –  Aadit M Shah Aug 15 '13 at 23:20
@AaditMShah: If you just want to play around then to whatever you want. That said, not working on strict mode is a big limitation and I would say that inspecting the call stack like that breaks lots of encapsulations and is generally on the "evil" side of things. –  hugomg Aug 15 '13 at 23:25
This is what I cooked up: jsfiddle.net/tRg4w It depends upon the following gist: gist.github.com/aaditmshah/6241369 –  Aadit M Shah Aug 15 '13 at 23:38
@AaditMShah that is pretty neat although other acceptable solutions are available at no performance loss but that is indeed best on the "API" side :P –  Esailija Aug 15 '13 at 23:46
Not only is it not allowed in strict mode everything except the arguments object are deprecated and will be removed in future versions of javascript. So, the consensus is not to not use it. The consensus is that they practically don't exist. –  slebetman Aug 16 '13 at 9:05
add comment

If performance is your only concern, it's probably fine. While massively slower than not referencing caller, my machine can still do that 1.6 million times per second.

"Slow" can be a relative term. If you only need to call it rarely, it does it's magic fast enough most of the time. I just wouldn't put it in a big loop, iterated on every animation frame in my game.

However, this magic property has other problems. There are are more concerns than just performance, as @missingno points out.

share|improve this answer
That is not the point but affecting the inlineability of a function. Its effects cannot be looked at like this because it's an enabling optimization which can radically change the code that runs because the compiler can see much more at once –  Esailija Aug 15 '13 at 23:19
add comment

Your Answer


