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 
<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

Reply via email to