<div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>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: <a href="https://github.com/apple/swift/commit/2cdd7d64e1e2add7bcfd5452d36e7f5fc6c86a03">https://github.com/apple/swift/commit/2cdd7d64e1e2add7bcfd5452d36e7f5fc6c86a03</a>.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 5, 2016 at 11:47 AM, Brian Gesiak <span dir="ltr"><<a href="mailto:modocache@gmail.com" target="_blank">modocache@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Ben,<div><br></div><div>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 <a href="https://github.com/apple/swift/commit/18c75928639acf0ccf0e1fb6729eea75bc09cbd5" target="_blank">https://github.com/apple/<wbr>swift/commit/<wbr>18c75928639acf0ccf0e1fb6729eea<wbr>75bc09cbd5</a>, which adds a -warn-long-function-bodies option that you may be able to use.</div><div><br></div><div>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.<br><br>Personally, I think the Swift compiler should provide users with more information about compilation times. In <a href="https://bugs.swift.org/browse/SR-2741" target="_blank">https://bugs.swift.org/<wbr>browse/SR-2741</a>, 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.</div><div><br></div><div>- Brian Gesiak</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Tue, Oct 4, 2016 at 5:38 PM, Ben Asher via swift-dev <span dir="ltr"><<a href="mailto:swift-dev@swift.org" target="_blank">swift-dev@swift.org</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr">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-bo<wbr>dies) 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).<div><br></div><div>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.</div><div><br></div><div>Thanks!<span class="m_-6230974228964068924HOEnZb"><font color="#888888"><br clear="all"><div><br></div><div class="m_-6230974228964068924m_1017188173920452490gmail_signature"><div dir="ltr">Ben</div></div>
</font></span></div></div>
<br></div></div>______________________________<wbr>_________________<br>
swift-dev mailing list<br>
<a href="mailto:swift-dev@swift.org" target="_blank">swift-dev@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-dev" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-dev</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">-Ben</div></div>
</div>