<div dir="ltr">+1<div>The first thing I do in a new project is always to enable WMO.</div><div><br></div><div>My impression/experience is that slow compile times often have to do with the type checker; I use</div><div>-Xfrontend -debug-time-function-bodies<br></div><div>to see in which funcs the type checker spends "too much" time, edit them and repeat until compile time goes down. The first time I did this I had a project in which the compile time was about 10 seconds and it went down to less than a second after I had identified and reformulated ten or so time consuming parts of my code.</div><div><br></div><div>However, especially for bigger project, viewing the time/func-output in Xcode's Report Navigator is quite far from a pleasant experience.</div><div>The contents of the view is painfully slow, and it is not possible to sort/order/filter the time/func-entries etc.</div><div><br></div><div>An improved report of where the compile time is spent (not only time/func but time/code-location) would be a very valuable tool until compile times becomes less erratic and expressions like eg this:</div><div><div>let dictionaryOfIntOps: [String: (Int, Int) -> Int] = [</div><div>"+": (+),</div><div>"-": (-),</div><div>"*": (*),</div><div>"/": (/),</div><div>]</div></div><div>is no longer considered "too complex to be solved in reasonable time" (commenting out one of the four elements will make it compile).</div><div>Also, there are other seemingly simple expressions that are slow but not too slow / too complex.</div><div>And as the sum of a project's all "reasonable times" quite often ends up being kind of unreasonable, we need a reasonable tool to help us help the compiler/type-checker (by quickly pointing us to the most time consuming parts of the code so we can reformulate it).</div><div><br></div><div>/Jens</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 11, 2016 at 7:47 PM, Nadav Rotem via swift-dev <span dir="ltr"><<a href="mailto:swift-dev@swift.org" target="_blank">swift-dev@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
Many of us have considered it a long-term goal to make whole-module optimizations the default compilation mode for Release builds. I believe that we are ready and that we should enable WMO by default. WMO solves real problems but comes at a cost. Let’s discuss this and make a decision.<br>
<br>
Today, each swift file is compiled and optimized independently. Compiling each file independently makes our compile times relatively fast because multiple files are optimized in parallel on different CPU cores, and only files that have been modified need to be recompiled. Both Debug and Release builds use this technique.<br>
<br>
However, the current compilation mode is not that great for the performance of the generated code. File boundaries are optimization barriers. Swift users found that when they develop generic data structures (like Queue<T>) the performance of these data structures was not ideal, because the compiler was not able to specialize the generics into concrete types (turn T into an Int for all uses of Queue<T>). Our recommendation was to either copy the generic data structures into the files that use them or enable WMO[1].<br>
<br>
With WMO all of the files in the module are optimized together and the optimizer is free to specialize generics and inline functions across file boundaries. This compilation mode is excellent for performance, but it comes at a cost. Naturally, WMO builds take longer because the compiler can’t parallelize the build on multiple cores. Also, every change in a single files makes the compiler re-optimize the whole program and not only the file what was modified.<br>
<br>
We’ve been working to improve our WMO builds in a number of ways. Erik (@eeckstein) found that we spent most of our compile time in code generation optimizations (such as instruction selection and register allocations) inside LLVM, and was able to split the Swift module into multiple units that LLVM can compile in parallel. He also implemented cacheing at the LLVM level that improved the performance of incremental builds. Unrelated to the work on WMO, we also improved the speed of the optimizer by tuning our optimization pipeline and the different optimizations - and in the last three months we improved the overall compile time of optimized builds by ~10%.<br>
<br>
Another concern was the increase in code size. In WMO mode we are free to specialize generics and inline code between files. These optimizations can increase the size of the generated program significantly. We also made a huge progress on this front. We were able to reduce the size of the Swift dylib that builds with WMO from 4.6MB in January to 3.7MB today.<br>
<br>
We should not enable WMO for Debug builds. We don’t do any major optimizations on Debug builds and compiling things in WMO will only slow the compile times and not provide any speedups. We strive to make Swift Debug builds as fast as scripts (and intend to allow people to use #!/bin/swift), so unjustified reduction in compile time is unacceptable.<br>
<br>
To summarize, WMO is critical to the performance of optimized Swift programs. WMO increases code size and compile times but we’ve made excellent progress and we’ll continue to invest in these areas. I believe that considering the inherit tradeoffs, enabling WMO is a good idea.<br>
<br>
Please let me know what you think.<br>
<br>
Thanks,<br>
Nadav<br>
<br>
[1] - <a href="https://developer.apple.com/swift/blog/?id=27" rel="noreferrer" target="_blank">https://developer.apple.com/swift/blog/?id=27</a><br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
swift-dev mailing list<br>
<a href="mailto:swift-dev@swift.org">swift-dev@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-dev" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-dev</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">bitCycle AB | Smedjegatan 12 | 742 32 Östhammar | Sweden<br><a href="http://www.bitcycle.com/" target="_blank">http://www.bitcycle.com/</a><br>Phone: +46-73-753 24 62<br>E-mail: <a href="mailto:jens@bitcycle.com" target="_blank">jens@bitcycle.com</a><br><br></div>
</div>