Successfully improving function call performance
We haven’t had much luck in our attempts to improve the runtime performance of Elm’s function calls, but there’s still one thing left to try. What happens when we combine the fast-path approach of our previous attempt, with the slow-path approach of Elm’s current implementation?
In our previous attempts, we’ve tried making the fast path of executing a function faster, or at least remain as fast as it was. However, this has come at the expense of making the curried/slow path slower, and the solution in general more complex. What if we try to improve the fast path without doing anything that affects the slow path?
In our previous article, we tried to encode the arity of the function into the shape of the function itself by storing the original function in an .ax property on the curried version, thus not needing an arity or an arity check at all. Let's try a minimal version of that.
Seems to be a good improvement. In the few cases where have a regression, the regression is small enough to be within the margin of error.
