[swift-dev] Reporting/Debugging Slow Swift Compile Time
benasher44 at gmail.com
Wed Oct 5 17:37:39 CDT 2016
I just tried with both Xcode 8.1 beta 2 and Xcode 8.0, and 8.1b2 seems
maybe 15s faster (to build our main huge target): 7m28s compared to 7m43s.
It's some improvement, but I'm not exactly sure what kind of improvement
Is there any profiling/tracing you all would recommend to help find problem
areas? I don't mind building from Swift master, using someone's preferred
profiling tools, etc. I'm not really sure where to start.
On Wed, Oct 5, 2016 at 1:05 PM, Ben Asher <benasher44 at gmail.com> wrote:
> Apologies for not starting off with system info: macOS Sierra (10.12.0),
> Xcode 8.0 (from the App Store).
> I'll try with Xcode 8.1 beta this afternoon and report back. Ill also open
> a ticket for improving -debug-time-function-bodies if I can confirm
> On Wed, Oct 5, 2016 at 1:00 PM, Mark Lacey <mark.lacey at apple.com> wrote:
>> On Oct 4, 2016, at 2:38 PM, Ben Asher via swift-dev <swift-dev at swift.org>
>> Hello! I work with a large project (~900 .swift files and more .m files).
>> We have a nightly job that compiles the app and calls out function bodies
>> (using -debug-time-function-bodies) that are slower than 100ms to
>> compile. Since upgrading to Swift 3, the number of trouble function bodies
>> has one from > 150 to < 20, so we're really happy about that! The only
>> issue though is that build time overall increased by ~1 min (amount of time
>> to build all targets before automatically merging to master in our
>> integration build).
>> Is this using a particular release of Xcode (8.0 or an 8.1 beta?), or
>> with one of the toolchain builds from swift.org?
>> Xcode 8.1 beta 2 includes some type checker performance improvements
>> which might have an impact here.
>> To dig into this further, we've started a new nightly job that builds the
>> app using the -debug-time-compilation flag, and using that we've found that
>> some files take as long as 2-3 seconds to compile. But, there's no targeted
>> output to help us get this down via the -debug-time-function-bodies flag
>> (i.e. no function bodies that we can refactor to get compile times much
>> One thing to look out for here is that I believe there are some cases
>> where -debug-time-function-bodies isn’t reporting type checking time. From
>> my (potentially faulty) recollection, things like let bindings with
>> literals or closures on the right hand side do not show up in the
>> -debug-time-function-bodies output, and depending on the specifics of the
>> expression these can sometimes take a long time to type check. When these
>> appear within the body of another type declaration they can end up getting
>> type checked multiple times during a full project build, and that time can
>> add up.
>> I don’t believe there is a bug open for improving
>> -debug-time-function-bodies to help diagnose this, but opening a bug would
>> be appreciated if you can confirm that this is the case, and of course
>> patches to fix it are definitely welcome as well.
>> We can see that most of the time is spent in "Type checking / Semantic
>> analysis" for these problem files, but we don't currently have any way of
>> knowing what that means. It feels like we've exhausted the available
>> options at this point (unless there are other flags I'm missing) in terms
>> of existing actionable debugging/profiling/reporting, so now our question
>> is this: what kind of reports would Swift maintainers be interested in
>> seeing in terms of output from profiling tools, etc. to help debug/diagnose
>> these slow compile issues? We're willing to devote time to tooling to help
>> generate such reports and file bugs.
>> swift-dev mailing list
>> swift-dev at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-dev