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

[Graydon Hoare]

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 at 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 <benasher44 at gmail.com <mailto:benasher44 at 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.lacey at apple.com <mailto:mark.lacey at apple.com>> wrote:
> 
>> On Oct 4, 2016, at 2:38 PM, Ben Asher via swift-dev <swift-dev at swift.org <mailto: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).
> 
> 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 at swift.org <mailto:swift-dev at 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 at swift.org <mailto:swift-dev at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-dev <https://lists.swift.org/mailman/listinfo/swift-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20161005/8bd412b3/attachment.html>