Debunking The Expensive Exported-Function Call Myth

[Luke Gorrie]

Bjorn Gustavsson <bjorn@REDACTED> writes:

> After some discussion in the OTP group, we have decided NOT
> to implement any support for calling a local function.

Fair enough.

> James Hague <james.hague@REDACTED> writes:
> 
> > Does the compiler not take advantage of functions being internal to a
> > module?  For example, if a function always returns a tuple which is
> > immediately unpacked, then the tuple construction can be avoided and
> > the values returned in Erlang registers.  At least I recall reading
> > about this somewhere.
> > 
> > If this is the case, then you wouldn't be able to call internal
> > functions directly.

This one seems easy. Suppose you have this code:

  foo() -> {A, B} = bar(), ...code...
  bar() -> {1, 2}.

then the optimized version (using Core Erlang syntax for
<Multiple,Values> in registers syntax) is something like:

  foo() -> <A, B> = bar(), ...code...
  bar() -> <1, 2>.

then to support calling bar/0 externally you'd need a tiny little
wrapper that calls the optimized one and packs the result into a
tuple:

  foo() -> <A, B> = opt(), ...code...
  opt() -> <1, 2>.
  bar() -> <A, B> = opt(), {A, B}.

This way the optimization would also benefit people using export_all.
Note: That includes everyone using embedded yaws. :-)