Open Radar

 
Summary:
Frameworks are a nice tool to split code into separate modules with obvious benefits.

However, one potential drawback is reduced optimization potential and in turn performance. In many cases this performance deficit is negligible or does not matter but in many performance sensitive areas it can be crippling, forcing more monolithic codebases.

Therefore it would be nice if Swift or the surrounding infrastructure included ways to alleviate this problem.


A good example could be a Framework containing a generic data structure. Depending on the data structure, proper specialization and inlining can make a huge performance difference between having the data structure code in the same module (and compiling with Whole Module Optimization) vs. in a Framework.


There are many possible ways to deal with this issue, just to list a few:

* For Frameworks where the source code is available, the compiler could do 'cross-module-optimization', i.e. compile the code from multiple modules at the same time. This would essentially be the same as putting all the same source files in the same module but without needing to actually do that and while maintaining the module abstractions.
An option would be to introduce an attribute to opt-into this behaviour to reduce the amount of code that is actually compiled in this way which could be applied to performance sensitive types/functions/...
Another option would be to introduce an alternative way to group code into modules instead of Frameworks that would not be compiled itself but simply aid in the logical grouping of code and always include source code so it can be compiled alongside the final target but independently maintained, tested, etc...


* LTO is an option and might bring some performance gains but is unlikely to be as good as proper high-level optimization from the Swift compiler.


* An option to include (for example) SIL in Frameworks to allow high level optimization by the compiler when using that Framework.


* Not sure how applicable it is, but whatever the standard library is using... When compiling against the standard library, the compiler aggressively inlines & specializes. Since the standard library is essentially part of the compiler it can of course do this in whatever way it chooses so this might not be generalizable. But it certainly seems like its doing more than just applying @transparent to everything ;-)

Steps to Reproduce:


Expected Results:


Actual Results:


Version:
OS X 10.11 (15A282b)
Version 7.1 beta (7B60)
Apple Swift version 2.0 (swiftlang_PONDEROSA-700.1.100.2 clang-700.1.74)