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 <modoca...@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@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@swift.org >> https://lists.swift.org/mailman/listinfo/swift-dev >> >> > -- -Ben
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
