> On Oct 4, 2016, at 2: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).
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 <http://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 faster). 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. Mark > 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
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
