<div dir="ltr"><font face="arial, helvetica, sans-serif" style="font-size:12.800000190734863px">Hello all!</font><div><font face="arial, helvetica, sans-serif" style="font-size:12.800000190734863px"><br>I&#39;m looking for a body of work to do on the Swift compiler for an upcoming programmer retreat I&#39;m attending in January [1]. I&#39;ve read a lot of blog posts with tips for diagnosing slow Swift compile times [2], and I was wondering if I could contribute to tooling in this area.</font><div><font face="arial, helvetica, sans-serif"><span style="font-size:12.800000190734863px"><br></span></font></div><div><font face="arial, helvetica, sans-serif"><span style="font-size:12.800000190734863px">(Just to make it clear: I&#39;m talking about improving and expanding the set of tools developers have to figure out why their projects take a long time to compile. I&#39;m *not* talking about working on speeding Swift compile times -- although the tools may indirectly help with that.)<br></span></font><div><div><div style="font-size:12.800000190734863px"><font face="arial, helvetica, sans-serif"><br></font></div><div style="font-size:12.800000190734863px"><font face="arial, helvetica, sans-serif"># Current state: many options, but few &quot;supported&quot; ones<br></font><div><font face="arial, helvetica, sans-serif"><br>Most of the blog posts I&#39;ve been reading talk about using the `-driver-time-compilation`, `-debug-time-compilation`, `-debug-time-function-bodies`, `-warn-long-function-bodies=`, and `-warn-long-expression-type-<wbr>checking=` options. I saved some sample output from each of these options <a href="https://gist.github.com/modocache/3fb21f5dc7fec6f300cacbe6c74c59d2" target="_blank">here</a>.<br><br>Using these options, developers can find function bodies and expressions that took longer to compile than others.<br><br>However, it should be noted that, of these options, only the first is a user-facing &quot;supported&quot; option. The others are `swift -frontend` options, and as such the Swift team has been clear that this means the options may be changed or removed at any point in the future [3].<br><br>What&#39;s more, several contributors have noted the behavior of the options themselves could also be improved. Here&#39;s what I gathered from reading several JIRA bugs, commit messages, and mailing list discussions:<br><br>- <a href="https://bugs.swift.org/browse/SR-2910" target="_blank">SR-2910</a> points out that `-debug-time-function-bodies` prints just `get {}` and `set {}` for struct getters and setters, and that this could be improved by printing the variable name as well.</font><div><font face="arial, helvetica, sans-serif">- The commit that added `-warn-long-function-message=` notes in <a href="https://github.com/apple/swift/commit/18c75928639acf0ccf0e1fb6729eea75bc09cbd5" target="_blank">its commit message</a> that the option only measures some aspects of type-checking, that it doesn&#39;t provide any information on how checking a function for the first time will take longer, doesn&#39;t report on other phases of compilation, and doesn&#39;t catch anything being type-checked multiple times.</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">In part because the options don&#39;t provide the functionality described in the commit message above, the impression I&#39;ve received has been that the Swift team is not enthusiastic about exposing these options outside of `-frontend`. From the comments on <a href="https://bugs.swift.org/browse/SR-2741" target="_blank">SR-2741</a>, Jordan Rose writes:</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">&gt; <span style="color:rgb(51,51,51)">I&#39;m leery of &quot;productizing&quot; `-debug-time-function-bodies` in any way because it&#39;s already not a true story. Import and decl-checking costs that come up for the first time during a particular function get ascribed to that function. SILGen, optimization, and LLVM costs are ignored entirely. Decl-checking costs that are *not*</span><span style="color:rgb(51,51,51)"> </span><span style="color:rgb(51,51,51)">within a particular function are also ignored. </span><span style="color:rgb(51,51,51)">The only useful purpose of `-debug-time-function-bodies` is to see if the type checker is spinning on a particular function.</span></font></div><div><font face="arial, helvetica, sans-serif"><span style="color:rgb(51,51,51)"><br></span></font></div><div><font face="arial, helvetica, sans-serif"><span style="color:rgb(51,51,51)"># The question of whether to &quot;productize&quot; these options</span></font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">Further, other contributors have expressed misgivings about &quot;productizing&quot; these as well. In <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20161003/003099.html" target="_blank">an email thread named &quot;Reporting/Debugging Slow Swift Compile Time&quot;</a>, Ben Asher writes:</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">&gt; I understand Jordan&#39;s response (in SR-2741) of being &quot;leery of &#39;productizing&#39;&quot; these flags. Developing with Swift shouldn&#39;t involve fighting the compiler to get the best compile time, so making this more than a debug flag does seem odd/worrisome.</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">I sympathize with this viewpoint, but I am concerned by three things:</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">1. The Swift team has been very clear that these options are &quot;unsupported&quot;, so my impression is that they&#39;re not quite the same as &quot;debug flags&quot;. `-driver-print-jobs` or `-###`, for example, are handy debugging options that are, I think, &quot;supported&quot;. They&#39;re not hidden behind the `-frontend` option.</font></div><div><font face="arial, helvetica, sans-serif">2. It seems like the reality is that many professional Swift developers use these *unsupported* options (again, not simply &quot;debugging options&quot;, but unsupported `-frontend` options) every day in order to measure their compilation times and keep them under control.</font></div><div><font face="arial, helvetica, sans-serif">3. One argument for keeping these options &quot;unsupported&quot; is that these professional developers won&#39;t need these `-frontend` options once the Swift compiler becomes fast enough, at which point they could potentially be removed without any room for complaint. But some large mobile application teams work on codebases that take over an hour to compile, and are compiled and hundreds of times each day. For teams such as these, the Swift compiler will never be &quot;fast enough&quot;. In environments where shaving 1% or 2% off of compilation time results in large CPU and energy consumption savings, I think engineers will always want to narrow down compilation time bottlenecks, and those engineers would probably want a &quot;supported&quot; set of options in order to do so -- that is, they&#39;d rather not use options that &quot;may be removed without notice at any future date.&quot;</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">So, it&#39;s my opinion that work should be done to provide a &quot;supported&quot; set of options to help diagnose why a Swift compilation is taking a long time, and I&#39;d like to work on that in January.</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif"># Ideas for &quot;supported&quot; options, and other future work?</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">I&#39;m 100% in agreement that options like `-debug-time-function-bodies` should not be brought out from behind the `-frontend` option in their current form. As I noted above, members of the Swift team consider these options to provide inaccurate data. Even if the data was accurate, its output is in an ad-hoc textual format, which is more difficult to machine-parse than other formats.</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">I&#39;d like to solicit ideas for future work here:</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">- At the very least, I could fix </font><a href="https://bugs.swift.org/browse/SR-2910" target="_blank">SR-2910</a>.</div><div>- I&#39;d also like to address some of the issues mentioned in <a href="https://github.com/apple/swift/commit/18c75928639acf0ccf0e1fb6729eea75bc09cbd5" target="_blank" style="font-family:arial,helvetica,sans-serif">this commit message</a>, but I would like to confirm they&#39;re still something the Swift team would like work to be done on. Jordan, are these still relevant?</div><div>- I&#39;m wondering if anyone else has some work in-flight here, or if they have ideas. If you&#39;ve been longing for a &quot;killer feature&quot;, please reply here and let me know!</div><div><br></div><div>- Brian Gesiak</div><div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">[1] See <a href="https://www.recurse.com/blog/121-come-to-rc-for-a-one-week-retreat" target="_blank">the blog post</a> for more details. Please let me know if you&#39;re also applying to go, especially if you&#39;re thinking of working on Swift! It would be great to have a buddy :)</font></div><div><font face="arial, helvetica, sans-serif">[2] Examples: <a href="https://github.com/fastred/Optimizing-Swift-Build-Times" target="_blank">1</a>, <a href="https://www.swiftbysundell.com/posts/improving-swift-compile-times" target="_blank">2</a>, and <a href="http://irace.me/swift-profiling" target="_blank">3</a>.<br>[3] <a href="https://github.com/apple/swift/commit/18c75928639acf0ccf0e1fb6729eea75bc09cbd5" target="_blank">This commit message</a> states “As a frontend option, this is UNSUPPORTED and may be removed without notice at any future date.”</font></div></div></div></div></div></div></div></div></div>