Does function inlining affect JIT compilation?

[Sebastian Poręba]

After reading some JIT docs I started to think if inlining a function
may be a bad thing for performance.
What if we have a function that could be JITed but the compiler
inlined it into a function that couldn't (for any reason)?

[John Lenz]

I have made the occasional tweak to prevent performance degradation (I wrote most of the inlining code), for instance, we don't inline into functions containing eval. And I am aware inlining can affect performance in a number of ways:

1) good: it avoids function call overhead

2) good: it can reduce code complexity as it changes code from general to specific (allow propagation of constants, dead code removal, etc)

3) bad: it can increase the complexity of the function into which a call was inlined (potentially increasing JIT latency and cost by including code that possibly won't be run or preventing it altogether)

For this last, I just don't have any data as to what is good or bad for all the JS engines and rely on the engines doing a good job in the general case (or equally bad job as the case may be).  

The compiler has traditionally tried to strike a balance between code size and performance but the compiler errors on code size.  This has worked out pretty well as (a) application generally aren't performance sensitive and (b) it is usually a performance gain (c) what is good for code size doesn't change with each browser release.  

That said, I will happily tweak the general inlining costing heuristic if someone can provide test cases where the results are uniformly or egregiously bad and have no objection to having a "performance" costing heuristic if someone wanted to experiment in that area for a particular engine.

[Alan Leung]

On Sat, Dec 3, 2011 at 3:58 AM, Sebastian Poręba <sebastia...@gmail.com> wrote:

After reading some JIT docs I started to think if inlining a function
may be a bad thing for performance.
What if we have a function that could be JITed but the compiler
inlined it into a function that couldn't (for any reason)?

On some occasions it is possible. The V8 team has reported to us once that a very hot function was inlined and the resulting code was too big for the JIT to consider optimizing it. However, they also found that the un-inlined version ran very slow in other browser.s

On Sat, Dec 3, 2011 at 9:59 AM, John Lenz <conca...@gmail.com> wrote:

I have made the occasional tweak to prevent performance degradation (I wrote most of the inlining code), for instance, we don't inline into functions containing eval. And I am aware inlining can affect performance in a number of ways:

1) good: it avoids function call overhead

2) good: it can reduce code complexity as it changes code from general to specific (allow propagation of constants, dead code removal, etc)

3) bad: it can increase the complexity of the function into which a call was inlined (potentially increasing JIT latency and cost by including code that possibly won't be run or preventing it altogether)

For this last, I just don't have any data as to what is good or bad for all the JS engines and rely on the engines doing a good job in the general case (or equally bad job as the case may be).  

The compiler has traditionally tried to strike a balance between code size and performance but the compiler errors on code size.  This has worked out pretty well as (a) application generally aren't performance sensitive and (b) it is usually a performance gain (c) what is good for code size doesn't change with each browser release.  

That said, I will happily tweak the general inlining costing heuristic if someone can provide test cases where the results are uniformly or egregiously bad and have no objection to having a "performance" costing heuristic if someone wanted to experiment in that area for a particular engine.

There are other considerations too. JITing is also computationally expensive on the client too. In most cases you probably don't want to worry too much unless you have something very computationally intensive application. Like John said, if anyone ever found anything that is really worthwhile, we are always happy to tweak our inlining heuristics.