<div dir="ltr">Thanks for the reply, Graydon, and for <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20171113/006001.html" target="_blank">your other email on the topic</a>!<div><br></div><div>I need to take more time to look into some of the things you mentioned, but I won&#39;t be able to do so in earnest for another few days. In the meantime, I&#39;ll just reply with a few uninformed opinions -- feel free not to respond to these :)<br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 17, 2017 at 12:54 AM, Graydon Hoare <span dir="ltr">&lt;<a href="mailto:ghoare@apple.com" target="_blank">ghoare@apple.com</a>&gt;</span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><div>Sadly, there&#39;s not always a 1:1 mapping between source entities and time like that. Certainly _some_ cases can be so egregious (say, typechecking time on an expression that&#39;s triggering an exponential-time inference) that they dominate compile time, and can be identified-and-fixed in isolation; but often the total amount of work attributable to a given source entity is spread around the compilation, occurs in multiple phases, emerges out of interaction between entities, overlaps with others, etc.</div></div></div></blockquote><div><br></div><div><div>It&#39;s these particularly egregious cases that I had in mind when I wrote my email. Many blog posts on &quot;how to reduce your Swift project compile times&quot; suggest one of the following approaches:</div><div><br></div><div>1. Use `-debug-time-function-bodies` and `-debug-time-expression-<wbr>checking` to print a list of times, sort those lists in descending order of time spent, and add explicit types to, or otherwise simplify, the slowest functions and expressions.</div><div>2. Use `-warn-long-function-bodies=` and `-warn-long-expression-type-<wbr>checking=`. Compile the project several times, gradually lowering the thresholds passed to these options, in order to surface the slowest functions and expressions. Add explicit types to or otherwise simplify the slowest functions and expressions.</div></div><div><br></div><div>My original idea was to expand or improve these options, since I think they&#39;ll continue to be useful for large Swift projects. But I&#39;m certainly open to working on something else instead.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><div>I don&#39;t have an especially strong feeling about the degree-of-support / stability of such features; I&#39;m going to have to leave that part of your question to others.</div></div></div></blockquote><div><br></div><div>Yeah, this is definitely still an open question of mine. In the meantime I&#39;ll try looking at some of the other approaches you&#39;ve suggested (thanks!).</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div>  1. See if you can leverage the existing counters and stats-gathering / reporting machinery in the compiler; for example the -trace-stats-events infrastructure lets you bundle together work done on behalf of a given source range and any changes to compiler counters during that work, as a single virtual &quot;stats-event&quot; in processing, and trace those events to a .csv file. Maybe something related to that would be helpful for the task you&#39;re interested in?<br></div></div></blockquote><div><br></div><div>I wasn&#39;t aware of `-trace-stats-events`, thanks! When using `-stats-output-dir` with a primary-file compilation mode, I can see that the stats include the amount of time spent on each Swift module being produced. I&#39;ll need to take a closer look at how `-trace-stats-events` works, though -- I get an empty .csv file when I use that option in conjunction with `-stats-output-dir`, and I&#39;m not sure yet how to use it with source ranges. I&#39;ll look into this further.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div>  2. Consider going up a level from declarations or functions to _files_, and see if there&#39;s a useful way to visualize hot-spots in the inter-file dependency graph that the driver interprets, during incremental compilation. The units of work at this level are likely to be large (especially if they involve cascading dependencies, that invalidate &quot;downstream&quot; files) and often cutting or changing an edge in that graph can be a simpler matter of moving a declaration, or changing its visibility: reasonably easy changes that don&#39;t cost the user much to experiment with.</div><div><br></div><div>Hope that helps! Happy to discuss any of this further.</div></div></blockquote><div><br></div><div>Yes, thank you! I&#39;m also interested in the &quot;improving incremental mode&quot; section of your other email, so thanks for writing all that down.</div><div><br></div><div>- Brian Gesiak</div></div><br></div></div></div>