[swift-dev] Reporting/Debugging Slow Swift Compile Time

[Brian Gesiak]

Hi Ben,

I'd really like to see improvements here as well. I don't know what reports
would be useful to the Swift team, but allow me to point out
https://github.com/apple/swift/commit/18c75928639acf0ccf0e1fb6729eea75bc09cbd5,
which adds a -warn-long-function-bodies option that you may be able to use.

However, as stated in the commit message I linked to above, both
-debug-time-function-bodies and -warn-long-function-bodies are frontend
options. They are not officially supported, and may be removed at any time
without warning.

Personally, I think the Swift compiler should provide users with more
information about compilation times. In
https://bugs.swift.org/browse/SR-2741, Brian Michel (cc'ed) describes a
feature he'd like to see: structured output from the Swift compiler driver,
as an official, supported option. Your team's use case sounds very similar
to his, so I'd encourage you to chime in on that issue with your thoughts.

- Brian Gesiak


On Tue, Oct 4, 2016 at 5:38 PM, Ben Asher via swift-dev <swift-dev at swift.org
> wrote:

> 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).
>
> 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
> faster). 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.
>
> Thanks!
>
> Ben
>
> _______________________________________________
> swift-dev mailing list
> swift-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20161005/09a35760/attachment.html>