Thank you Jordan! This is a great starting off point. I'm thinking about proposing a "strict import" mode in swift: A compile flag that when turned on would require you to explicitly import any file that contained a dependency you needed (like in objective-c).
I'm going to spend more time looking over the docs and the output logs to see if this would be a feasible. If anyone has opinions or insights into this I would love to hear from you. Sam On Tue, Apr 5, 2016 at 9:08 PM, Jordan Rose <jordan_r...@apple.com> wrote: > Hi, Sam. I don't think we currently have a good answer for this built into > xcodebuild or xctool, and it's a reasonable idea. (Ideally all builds would > be fast enough that it wouldn't matter! That's obviously not where we are.) > > Since '-debug-time-function-bodies' is now public knowledge, I'll share > another one of our debugging flags, '-driver-show-incremental'. You can add > this to your "Other Swift Flags". The output isn't very detailed, though: > > Queuing Tree.swift (initial) > Queuing AdventureScene.swift (initial) > Queuing AdventureScene.swift because of dependencies discovered later > Queuing AppDelegate.swift because of dependencies discovered later > Queuing ChaseArtificialIntelligence.swift because of dependencies > discovered later > Queuing Character.swift because of dependencies discovered later > Queuing SpawnArtificialIntelligence.swift because of dependencies > discovered later > Queuing Goblin.swift because of dependencies discovered later > Queuing Cave.swift because of dependencies discovered later > Queuing AdventureSceneOSXEvents.swift because of dependencies discovered > later > Queuing HeroCharacter.swift because of dependencies discovered later > Queuing EnemyCharacter.swift because of dependencies discovered later > Queuing Boss.swift because of dependencies discovered later > Queuing SharedAssetManagement.swift because of dependencies discovered > later > Queuing Warrior.swift because of dependencies discovered later > Queuing Archer.swift because of dependencies discovered later > Queuing Player.swift because of dependencies discovered later > Queuing ArtificialIntelligence.swift because of dependencies discovered > later > > In this case, I took a version of the Adventure sample project and > modified "Tree.swift"; that triggered recompilation of several other files. > Unfortunately this view doesn't tell you how they're related, only which > ones are actually getting rebuilt. > > The next step (and moving into the territory of "working on Swift" rather > than just "trying to figure out why it's repeating work") would be to look > at the "swiftdeps" files stored in your DerivedData folder. These are > currently just YAML files describing what Swift thinks the file depends on, > as well as what will trigger rebuilding of other files. This is intended to > be a conservative estimate, since *not* recompiling something would > result in an invalid binary. (Unfortunately I say "intended" because there > are known bugs; fortunately, archive builds are always clean builds anyway.) > > There's a document in the Swift repo describing the logic behind Swift's > dependency analysis: > https://github.com/apple/swift/blob/master/docs/DependencyAnalysis.rst. > The one thing that's *not* in there is the notion of changes that don't > affect other files at all. This is accomplished by computing a hash of all > the tokens that *could* affect other files, and seeing if that hash has > changed. > > We definitely have room for improvement here. > > Jordan > > > On Mar 31, 2016, at 11:24 , Samantha John via swift-dev < > swift-dev@swift.org> wrote: > > I have a large project (308 swift files, 441 objective c, 66k lines of > code) where incremental builds can be extremely slow. I'm trying to do some > profiling to figure out what type of things cause large scale recompiles. > The problem is that I can't find a good way of telling which files get > recompiled on an incremental build and which do not. It seems like files > that are not recompiled still get listed in xcode, but the compiler just > passes over them really fast. > > Does anyone know if xctool or xcodebuild has this type of functionality? > Or is there some other way to get this info? > > Thank you, > Sam > _______________________________________________ > swift-dev mailing list > swift-dev@swift.org > https://lists.swift.org/mailman/listinfo/swift-dev > > >
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
