If you can collect an instruments profile of the frontend running one of the particularly-slow files, it might help localize the subsystem of the typechecker; aside from that, I'm currently putting some new counters and timers in the frontend, so am likely to have slightly more-constructive news in the next little while, but don't have that work done just yet.
For collecting an instruments profile, try something like: $ SWIFTBIN=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift $ instruments -t 'Time Profiler' $SWIFTBIN -frontend -parse somefile.swift $ open instrumentscli0.trace Then expand all (option-click the triangle next to 'swift' in the call-tree), select-all, copy and paste the complete call-tree into a text file and attach it here, that might give a bit of insight. On my local copy of instruments one also has to toggle the "separate by state" box of the details pane to get the full call-tree to expand, not sure why; might just be a transient bug. -Graydon > On Oct 5, 2016, at 3:37 PM, Ben Asher via swift-dev <swift-dev@swift.org> > wrote: > > I just tried with both Xcode 8.1 beta 2 and Xcode 8.0, and 8.1b2 seems maybe > 15s faster (to build our main huge target): 7m28s compared to 7m43s. It's > some improvement, but I'm not exactly sure what kind of improvement was > expected. > > Is there any profiling/tracing you all would recommend to help find problem > areas? I don't mind building from Swift master, using someone's preferred > profiling tools, etc. I'm not really sure where to start. > > Ben > > On Wed, Oct 5, 2016 at 1:05 PM, Ben Asher <benashe...@gmail.com > <mailto:benashe...@gmail.com>> wrote: > Apologies for not starting off with system info: macOS Sierra (10.12.0), > Xcode 8.0 (from the App Store). > > I'll try with Xcode 8.1 beta this afternoon and report back. Ill also open a > ticket for improving -debug-time-function-bodies if I can confirm anything. > > Thanks! > > Ben > > On Wed, Oct 5, 2016 at 1:00 PM, Mark Lacey <mark.la...@apple.com > <mailto:mark.la...@apple.com>> wrote: > >> On Oct 4, 2016, at 2:38 PM, Ben Asher via swift-dev <swift-dev@swift.org >> <mailto: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 <mailto:swift-dev@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-dev >> <https://lists.swift.org/mailman/listinfo/swift-dev> > > > > > -- > -Ben > > > > -- > -Ben > _______________________________________________ > swift-dev mailing list > swift-dev@swift.org <mailto:swift-dev@swift.org> > https://lists.swift.org/mailman/listinfo/swift-dev > <https://lists.swift.org/mailman/listinfo/swift-dev>
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
