Xcode 8 recompiles every file every build

Whenever I make a change to a file, like add a new property or create a new class, Xcode recompiles every single file on a build, and it takes quite some time. I've got this happening on the GM on two different computers (one running 10.12 one running 10.11).


I've tried:

  • copying every file to a new Xcode project created in Xcode 8 GM
  • removing every "Other swift flag" flag
  • removing all third party libraries
  • comparing my project's build settings to a new project's build settings
  • remove all test targets leaving just the one target I need
  • removing all ObjC code
  • removing all ObjC related flags


Really the kicker is that moving all my code to a new project shows that it's something in my code.

Any ideas? My productivity is way down having to wait ~ 1.5 minutes for every build / auto complete / syntax highlighting to work. And yes, I've cleared derived data 🙂



UPDATE:

One more peice of information, I found this information https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20160411/001693.html


which tells us about a "-driver-show-incremental" flag, which will cause queued dependancies to be listed in the build log. Sure enough I see what I think is every single swift file I have listed in the output. Trying to figure out if there's a way to make sense of what the dependancies are...


Output is something like:


...

Queuing Form.swift because of dependencies discovered later

Queuing SignInViewController.swift because of dependencies discovered later

Queuing EditProfileViewController.swift because of dependencies discovered later

Queuing ChangePasswordViewController.swift because of dependencies discovered later

Queuing JoinViewController.swift because of dependencies discovered later

...

Post not yet marked as solved Up vote post of aandrewc Down vote post of aandrewc
83k views

Replies

Hi Quinn,


Is there a particular toolset you recommend for the VMs?


Thanks for your help.

Is there a particular toolset you recommend for the VMs?

I use VMware Fusion for running my VMs but that’s more an accident of history than a deliberate choice (back in the day I had some friends working on that team). Unless you have other specific requirements, I suspect that any commercial product that officially supports Mac-on-Mac virtualisation would work fine for tests like this.

Mac-on-Mac virtualisation has worked really well for me. The only gotcha is that you don’t get graphics acceleration. This isn’t an issue for me (I work on low-level stuff, and thus don’t care about graphics) but I could see it being an issue for others.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

just 12 simple swift files: more than 8 minutes of compilation.


Terrible !

is there a way to moitor what a **** the compiler is doing during such amount of time ?

This just to verify wich is the main cause of this waste of time.

It might be interesting as an expiriment, if you removed from the build one file at a time and see if one file in particular is causing most of the build time. Perhaps, that might give a clue. Do that for release and debug to contrast. I'd suppose whole module optimization etc. would be off in debug. Start each run with a clean work space.


I'd wager the whole module optimization is making all the files one space and then it wants to recompile all the files even if only one file changes? Thus, the gripe. Link time optimization caused issues like this with c. So, there was the partial link time optimization as a work around -- but I'm not sure that option exists for Swift.


Perhaps ( wild guess ) it has something to do with sil? I suppose that is one difference contrasting with c's interaction with llvm? Now there is another step called sil.


Just throwing spaghetti at wall. Maybe something will stick.

Yes, the optimization is switched to "none" and it make no differences if set to "fastest".

Also isolating one file at the time does not help.


I am loooking for a way to monitor the compilation phases, but I do not know how to do it.

Hmm, when I build my workspace with two projects of 91 swift files and 7 Objective-C/C++ files on a mid 2012 MBP with ssd drive, it takes about 2:17 to compile with Xcode 8.2.1. I cleaned before I ran my test. If I build without the clean it takes about 20 seconds with signing taking most of the time.


I do not have find implicit dependencies or parallelize build checked in my schemas. ( mainly because I copy a framework )


All my project files are set to Xcode 8.0 compatible. Deplyment target iOS 10. No enable bitcode and no build active architecture only. Fast whole module optimization is on and legacy swift is off. Not a simulator build.

I have "discovered" that 7 minutes and 30 seconds on a total of 8 minutes of compilation are due to the "Signing product" phase.

My Code Signing Identity is set to "Don't Code Sign"


Any help ?

Hmm, my code signing was set to Automatic - iOS Developer . Though, if I make an archive for the store then it will be iOS Distribution. Provisioning profile is set to automatic. Code signing entitlements is blank.


Big files in your project?

No, just 12 swift source files and some hundreds of pictures to copy on the simulator.

The copy phase of the 450 pictures takes 20 seconds, while the "Signing product" takes more than 7 minutes.

Really frustrating.

Hmm, if I generate an ipa archive and rename it to .zip, then you can decompress and get to the bundle. Inside the bundle there is a _CodeSignature folder with a CodeResources file. Its just xml but there is a key for "files". My guess is that would have atleast 450 entries for your pictures. Each item looks like there is a base64 string associated with it. ( I can tell because there is a "=" on the end ... plus its xml ) So maybe there is some over head per file such that it takes 8 minutes generating somekind of signature.


Or perhaps some of those images are big -- like raw? Might just be one of them -- maybe an artist messed up. For kicks, as a test, if you did not include some of them in the project would it speed things up? Or any image file in particular? Having a large number if images should not be out of the ordinary for an app.


It might be interesting if you zipped all those images into one file, then when your app first runs decompress it out into multiple files. Or if they could be downloaded off a server when the app first runs then there would be no code signing for these images -- that might be a more scalable approach and then users could download the app on cell connections.


Random ideas...hope that helps.

I will make some tests with your suggestions, but the "Signing product" time seems not correlated to the number of images.

Just to mention, for a pair of times the compilation time was just 40 seconds or so, without any reason, but in the last 5 compilations, again, 8 minutes and more, just for signing the product.

PS: tried to compile with 10 pictures instead of 450; no differences at all...

Horrible !

When I build my code sign is doing something like:


CodeSign /Users/USER/Library/Developer/Xcode/DerivedData/XXXXXX-XXXXXX/Build/Products/Release-iphoneos/XXXXXX.app

cd /Users/USER/Desktop/ZZZZZZ/XXXXXX/XXXXXX

export CODESIGN_ALLOCATE=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/codesign_allocate

export PATH="/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:/Applications/Xcode.app/Contents/Developer/usr/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin"


Signing Identity: "iPhone Developer: XXXXXX (XXXXXX)"

Provisioning Profile: "iOS Team Provisioning Profile: com.XXXXXX.XXXXXX"

(XXXXXX)


/usr/bin/codesign --force --sign ZZZZZZ --entitlements /Users/USER/Library/Developer/Xcode/DerivedData/XXXXX-XXXXX/Build/Intermediates/XXXXX.build/Release-iphoneos/XXXXX.build/XXXXX.app.xcent --timestamp=none /Users/USER/Library/Developer/Xcode/DerivedData/XXXXX-XXXXX/Build/Products/Release-iphoneos/XXXXX.app


So, seems like there are limited options here. But what would bug me is I see timestamp, Intermediates and DerivedData. Maybe something is not being cleaned up from the last sign -- something left in derived data from the last build. In Xcode 8, there was a suspicious change with removing the ability to delete derived data etc. The only influence I can see in this step is cleaning out derived data and or not including files in a project to avoid the sign. But as a user, I should not have to worry about it ... it should just work. I guess it does but takes 8 minutes in your case.

One last follow up question, if you are using Mac OS Extended for your partition, is it case sensitive or not case sensitive? Perhaps that might cause some people to have issues and others not. My partition is not case sensitive ( probably is not a good idea for development )

I think the only way to solve this is to start contacting the technology press and point out how a trillion dollar company cannot fix for more than three months a bug that kills developer productivity entirely. This is completely ridiculous.