I've just updated Xcode to version 6.3. I'm working on a project in Swift with some imported Objective C code. I also use Cocoapods.
I had the same issue with the Xcode 6.3 beta. I've seen and tried all other StackOverflow answers with no luck.
So far I've tried to:
Delete ~/Library/Developer/Xcode/DerivedData and ~/Library/Caches/com.apple.dt.Xcode with Xcode and/or Mac restart.
Uninstall Spotify.
Not use the "+" concatenation operator.
Set deployment's target to 8.1.
I should mention that Objective C code autocompletes fast and that before indexing Swift code too. Esc button for popup suggestions works with the same delay.
Setting Whole Module Optimization to Yes is a workaround in my project.
In my case, the project has 5 modules, named here A, B, C, D and E, where the dependency is diagramed A -> B -> C -> D, and each of A to D refers E. With Xcode 6.3 and 6.3.1, it is fine to compile modules E and D, but it takes longer to compile C, and much longer to compile B and A, like 10 mins. After I change the project setting, it takes less than a min to compile all the modules. It looks faster than compilation with Xcode 6.2.
References:
Slow test file compilation in Swift 1.2, Xcode 6.3.1
https://devforums.apple.com/message/1128702#1128702
Try to clear project Derived Data, after update.
Window - Projects - YourProject - Derived Data - Delete...
In my case code completion is working better after update.
I used extensions on the GameScene Class and it sped everything up.
I took out three large functions from my gameScene Class, And made three separate extensions for them.
This is probably the easiest solution if none of the above work.
I got code completion down from several minutes to about 2-3 seconds for my large project.
Observation: although code completion considers 'everything' in a project, code completion was extremely slow when performed in one file and very ok when performed in another file.
The property of the slow file was one expression (filling an array with data) over several 1000 lines of code.
splitting the method with this expression up into 3 methods in 2 files (not 3 expressions in 1 method), I got the code completion speed from minutes to seconds.
It appears that there is a threshold where code completion gets slow. This is not a gradual thing where code completion gets slower and slower. It is either slow or fast. You don't have to split up your code into many methods. It is enough to get under the threshold.
This behaviour suggests a constraint in resources, maybe memory. My current machine has 16 GB memory.
So this is what you do:
check if code completion in one file is much slower than in others.
look for large or complex expressions in the slow file.
extract parts of the large expression into one or more separate methods. Probably not many extracts necessary. Start with one.
This issue appears to be fixed in Xcode 6.3.1 (released yesterday).
Related
After changing single line of code and performing Xcode 10.1 incremental build in large project, Xcode spends most of build time in "Compile swift source files" phase after completing all listed tasks (compile changed files and merge swiftmodule are both completed)
screenshot showing tasks list: https://imgur.com/a/JoVI0zB
While compilation and merging swift module takes less than second, whole phase can take up to 2min in my project (300k LOC).
What does Xcode do in this time? Is there any way to speed up this process?
Similar project written in Obj-C takes just few seconds to launch after changing 1 line of code.
I have this same issue and after a lot of investigation I have determined that whatever it is doing, it is based on the number of swift source files you have.
The Root Cause
In the 2018 wwdc talk about the Xcode build system the presenter says (searchable in the transcript of the video):
What this means is that unlike Clang, when compiling one Swift file, the compiler will parse all the other Swift files in the target.
So even if/though the incremental build only needs to recompile a single file, it still parses every other swift file.
Our project has over 2000 swift source files and we are seeing incremental build times of 3+ minutes for recompiling a single independent file.
Testing to prove the root cause
Because hearing it in a WWDC talk is not enough, I did the following to test it myself:
Created a new project
Tested incremental build times for nearly empty project, changing a single file
Incremental build completes nearly instantaneously (< 1-2 seconds)
Used a script to generate 2,000 swift files, each containing a simple struct with a unique name, 2 variables, and a simple function. There are no dependencies between any of the files.
Add the directory containing the 2,000 new swift files to the project and complete a full build.
Test incremental build times again for a single file
Incremental build time took more than 1 minute
In my testing, the complexity of the contents of the additional swift files does not seem to be significant, only the number of files.
The Solution - Modularization/Frameworks
Separate your app in to smaller frameworks to reduce the number of swift source files in each target.
This is a decent guide showing steps on how to go about this if you don't already know how.
In my test case above, I created a new framework and moved the 2,000 swift files into the framework and then tested incremental build times in the original project (importing the framework) and the build times were back to < 1-2 seconds. Of course doing an incremental build inside of the framework would still be slow, but ideally you would split the project into many and smaller frameworks so that each will have faster incremental build times.
Not the Solution - Merging Files
If the problem is the number of files, why not merge a bunch of files to reduce the number? Because it will likely result in slower incremental builds.
According to 2018 WWDC's Building Faster in Xcode:
Swift's dependency model is based around files
This relates to our current problem because it means that any change to a file (except for changes to function body contents only) will cause recompilation for any file that depends on ANYTHING in the changed file.
If you merge many types into a single file, it will result in more code getting recompiled on incremental builds if any of the changes touch the large file or any of its dependencies. It will also increase the number dependents the large file has, making it so all of them get recompiled if ANY of the types in the large file are modified.
Has anyone converted an app from 1.2 to Swift 2? My app is small - about 1k LOC, and its been converting for >2 hours now. I'm stuck on the following screen:
How long should I expect this to take? Thanks...
The process is long, but it shouldn't take more than several minutes.
The Swift converter is probably having an issue (e.g.: some kind of infinite loop).
You should abort and try to find what happened or maybe migrate manually.
Swift compiler has an issue with arrays. I have commented out all the elements of the array (like 10x UIColor), left only one element and conversion went smoothly.
Here's how you can debug the issue in your project:
Got to the Report navigator (CMD + 8)
Build your app, select the latest build and watch log (select All Messages filter)
The problematic file will be stuck on the compile status.
Navigate to that file and figure out what can hang the compiler (probably arrays/dictionaries).
Why build not convert? Because it's verbose.
We are working on a large design, for which the verification environment is complex. It contains 5 internal VIPs ( 3 of them we own and debug, doing minor changes and tweaks), CDNS unipro VIP and a low level services package we uses for all of our environments. Our e compilation flow is long and tedious, and for every change we make in our code base , our turnaround time for fixing is 10 mins.
How can we improve our compilation flow for increasing our team effectiveness?
Work in compiled mode.
Compile your code in parallel.
Use specman advance option which let you save and restore, reseed and dynamic load.
use multiple cores for much faster compilation time (-mc switch to sn_compile.sh). Requires advanced options license
Compile your code in compiled mode using multi core compilation. It will reduce the compilation time significantly.
You can use this compilation also for debugging instead of the interpreted mode.
This capability is already included in the last hotfix of your installed release.
You can compile your code. You can also use parallel compilation. Another thing you can do is to use reseed and dynamic load
Use SAO: use multi process compilation.
Download latest fix, as from version 13.1 you don't need a special verstion.
You can also use compiled code and compile only the modules you changed (multi stage compilation).
Starting version 14.1 you can compile the code to an elib file.
In addition to multiple cores compilation, from 14.1 can use elibs to prevent recompilation of modules that were not changed.
What we do for normal development is only compile the code that we will normally never change (base libraries, VIPs from other vendors, code reused from previous projects, etc.). Any code that we develop for that particular project is loaded interpreted on top. This gives a smaller turnaround time when we have to change something (because you just do a quick "reload").
For regression testing, we compile everything up to the testbench top and load the tests on top.
I just installed the cocos2d templates in Xcode 4. When I create a new project from the template and run it, it shows around 30 compiler errors. Even without making any changes to the template. Do you have any idea what is wrong?
Please add some more information about errors, but it looks like you forgot to add to your project OpenGLES and QuartzCore frameworks. I could be wrong...
I just spent 10 or 15 minutes plus fixing a bunch of errors in this situation, so i will guess: moving to Xcode 4.X caused many problems for cocos2d projects (including Kobold2D) and most of them require putting "(unsigned int)" in front of an argument in a list of arguments to a 'string with format' type operation creating mostly debug type output. usually the argument in question is "self", but sometimes just other "types" that resolve to (or can) unsigned ints. in a few cases I had no arguments but a reference to the error string to %#; these required adding a ", self" between the end of string and the close paren. in about 5 to 10% of cases, "fixits" were provided to automate the correction (usually changing the format character to match the argument). Hope this helps! Happy to provide examples if this actually helps anyone.
I have a workspace built using MS-Visual Studio 2005 with all C code.In that i see many functions which are not called but they are still compiled(they are not under any compile time macro to disable them from compiling).
I set following optimization settings for the MS-VS2005 project to remove that unused code:-
Optimization level - /Ox
Enable whole program optimization - /GL
I tried both Favor speed /Ot and Favor Size /Os
Inspite of all these options, when i see the linker generated map file, I see the symbols(unsed functions) names present in the map file.
Am I missing something? I want to completely remove the unused code.
How do I do this?
The compiler compiles C files one-at-a-time. Therefore, while compiling a C-file that does contains an unused function, the compiler cannot be sure that it will not be called from another file and hence it will compile that function too. However, if that function were declared as static (file-scope), then the compiler would know it is not used and hence remove it.
Even with whole program optimization, I think it would still not be done since the compilation could be for a library.
Linkers do something similar to what you are looking for. If your code links against a library containing multiple objects, then any objects that do not contain functions used by your code (directly or indirectly) would not be included in the final executable.
One option would be to separate your code into individual libraries and object files.
PS - This is just my guess. The behavior of the compiler (with whole program optimization) or linker essentially depends on the design choices of that particular compiler or linker
On our projects we have a flag set under the project properties\Linker\Refrences. We set it to Eliminate Unreferenced Data (/OPT:REF), according to the description this is supposed to remove function calls or data that are never used. I am just going by the description, I have never tested this or worked with it. But I just happened to see it within the last hour and figured it might be something you could try.