Hey Sam, One thought: if you have an app with mixed objc and swift code, then the app-bridge.h and app-swift.h files might be creating massive choke points in your dependency graph. I have no idea how optimized the bridging functionality is but it has always seemed like a potentially weak part of the dependency management. I imagine that with an objc half and a swift half of the code base, every time you make a change in a swift file you trigger recompilation of the objc half, and vice versa. I'd love to hear from the core team to what extent this is true!
George > On Apr 7, 2016, at 5:35 PM, Samantha John via swift-dev <swift-dev@swift.org> > wrote: > > 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 > <mailto: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 > <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 >> <mailto: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 <mailto:swift-dev@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-dev >> <https://lists.swift.org/mailman/listinfo/swift-dev> > > > _______________________________________________ > 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
