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

[Ben Asher]

I didn't know about that warning, so thanks for sharing that! Having this
enabled will help somewhat, at least in terms of keeping specific
slow-to-compile functions out of our master branch.

That said, I understand Jordan's response (in SR-2741) of being "leery of
'productizing'" these flags. Developing with Swift shouldn't involve
fighting the compiler to get the best compile time, so making this more
than a debug flag does seem odd/worrisome.

I'm more interested in the best way to get a feedback loop to understand
what the known issues are and see them addressed. This has already worked
well with fixes for big slowdown issues like SR-1277 and this well known
patch:
https://github.com/apple/swift/commit/2cdd7d64e1e2add7bcfd5452d36e7f5fc6c86a03
.

On Wed, Oct 5, 2016 at 11:47 AM, Brian Gesiak <modocache at gmail.com> wrote:

> 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/18c75928639acf0ccf0e1fb6729eea
> 75bc09cbd5, 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
>>
>>
>


-- 
-Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20161005/0b614a97/attachment.html>