I'd like to give some more information about the inliner changes I landed this week.
The goal was to restrict inlining to improve code size while not degrade performance (too much).
This was mainly achieved by improving the heuristic for the inlining decisions.
Some of our optimizations are still not as inlining-indepenent as we want them to be. Therefore I had to do some fine-tuning in the stdlib (e.g. with the new onFastPath builtin).
There are a few minor regressions, but overall performance looks ok.
The code size reductions are approximately:
stdlib: 3%
Benchmarks_O: 9%
Two larger applications: 15%, 20%
on Fri Apr 01 2016, Erik Eckstein <swift-dev-AT-swift.org> wrote:
Hi,
I'd like to give some more information about the inliner changes I landed this week.
The goal was to restrict inlining to improve code size while not degrade performance (too much).
This was mainly achieved by improving the heuristic for the inlining decisions.
Some of our optimizations are still not as inlining-indepenent as we
want them to be. Therefore I had to do some fine-tuning in the stdlib
(e.g. with the new onFastPath builtin).
There are a few minor regressions, but overall performance looks ok.
The code size reductions are approximately:
stdlib: 3%
Benchmarks_O: 9%
Two larger applications: 15%, 20%