<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">[+swift-dev again, for posterity]</div><div class=""><br class=""></div><div class="">Let’s see, those two are really mostly “I haven’t thought about how to recover from this scenario.” I have an internal presentation on why dependency analysis is the way it is that I should probably throw up in the docs in some format, but mostly these are all the occasions where dependencies change during a build, and I haven’t convinced myself one way or another whether the swiftdeps file left over from the last compilation is sufficient to represent what happened to a file that’s been removed.</div><div class=""><br class=""></div><div class="">Tasks more directly related to incremental builds aren’t really represented in JIRA because there aren’t many in digestible chunks. The most obvious improvements are all wrapped up in other things:</div><div class=""><br class=""></div><div class="">- Moving operators into types has the <i class="">potential</i> to stop making “==“ a top-level dependency on everything that defines “==“, but we haven’t figured out how yet. (Being part of a constraint system instead of being looked up as a member makes that hard, even though if we <i class="">pick</i> a member operator it must operate on one of the types involved.)</div><div class=""><br class=""></div><div class="">- Vtable layout depends on the methods in a class, so even if file A only calls one method in a class, adding a completely different method forces file A to be recompiled. This is probably the right trade-off in release builds, but not debug builds.</div><div class=""><br class=""></div><div class="">- Dependencies only use base names rather than full names, but default arguments make it hard to specify which full names are affected when a particular method is changed.</div><div class=""><br class=""></div><div class="">There are also two Radars about places where the incremental build logic seems to be incorrect; unfortunately I can’t share those projects. Obviously a bad incremental experience is still preferable to behavior changing on a clean build.</div><div class=""><br class=""></div><div class="">Tasks related to incremental builds also aren’t represented so much in Driver because at this point a lot of it’s about breaking dependencies and not being overconservative. The Driver generally can’t help with that; it just deals with the dependencies that the frontend spits out. The one thing we <i class="">could</i> do here is improve -driver-show-incremental. I haven’t used it in a while so I don’t actually know where I left off with that.</div><div class=""><br class=""></div><div class="">One thing we <i class="">have</i> noticed is that the cost for each frontend task for a project with 1500 tiny, non-dependent Swift files and a bridging header is much higher than it is for Clang. People have blamed Swift having to open and parse every file in the project, but I don’t actually believe this is the case; time spent in Parse is <i class="">tiny</i> for these functions. It would be very interesting for someone to investigate where this time is going. (There’s a similar project in <a href="https://bugs.swift.org/browse/SR-2461" class="">SR-2461</a>; I haven’t checked whether the project we have in Radar is appropriately clean of user info to share.)</div><div class=""><br class=""></div><div class="">I guess that’s about it. Oh, and I keep meaning to write tools to manipulate the data in the swiftdeps YAML files, but that can happen at any time. You’re welcome to contribute something before I get to it.</div><div class=""><br class=""></div><div class="">Definitely thanks for helping out here!</div><div class="">Jordan</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 26, 2016, at 11:35, Brian Gesiak <<a href="mailto:modocache@gmail.com" class="">modocache@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Although I was hoping to do more work on this over the weekend, so I'd really appreciate any pointers you had before then.<div class=""><br class=""></div><div class="">I'm currently looking into the "file removed" case that causes a complete rebuild -- the "FIXME: Distinguish errors from "file removed", which is benign." and "FIXME: Can we do better?" comments in lib/Driver/Driver.cpp. So if you have any insights into that, or really anything else, I'd love to hear them!<br class=""></div><div class=""><br class=""></div><div class="">- Brian</div></div></div></blockquote></div></body></html>