[swift-dev] Swift incremental compile profiling

[Samantha John]

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_rose at 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 at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160407/693f9b75/attachment.html>