koobas.hobune.stream
How to get faster script compilation?
I have a project of ever-increasing complexity, now with over 300 scripts, including editor scripts and plugins. Whenever I make a minor change to my scripts, it can take more than 15 seconds to compile, which is becoming a strain on productivity. Are there any ways I can speed this up?
I am familiar with the docs page on compilation, but I already have my scripts organized in the places they need to go. http://unity3d.com/support/documentation/ScriptReference/index.Script_compilation_28Advanced29.html
I also have wondered if compilation time is slower for javascript than C#. Most of my scripts are in javascript. It would be a pretty big task to rewrite them in C#, but if it made a significant difference I might put that on my to-do list.
Any tips from some pro users out there?
Thanks
I agree, this would be helpful, but I cant help you there. With my old computer, compiling large scripts takes a very long time.
Put the stable code in one of these folders: Standard Assets, Pro Standard Assets or Plugins, inside Assets.
According to this reference, those folders are compiled first, but the big thing is that Unity won't compile it if the code inside it didn't change. That's easier than creating DLLs with the advantage that you can modify the stable code.
The latest reference for Unity 4.x can be found here http://docs.unity3d.com/412/Documentation/ScriptReference/index.Script_compilation_28Advanced29.html
And yeah, I could confirm that it does reduce the compilation time.
"This reference" above is now here.
Essentially, the four mentioned compilation steps (Assets/Plugins -> Assets/Plugins/Editor -> Assets/* -> Assets/Editor) correspond to the (up to) four generated C#-projects ("Assembly-CSharp-firstpass" -> "Assembly-CSharp-Editor-firstpass" -> "Assembly-CSharp" -> "Assembly-CSharp-Editor"). Each project is compiled into a library-DLL of the same name (in Library/ScriptAssemblies), and each is dependent on their respective predecessor projects.
For file changes in Assets/*, only "Assembly-CSharp" has to be rebuilt, and DLLs of the predecessor projects can be used directly ("Assembly-CSharp-firstpass", "Assembly-CSharp-Editor-firstpass").
One problem with this approach is that the code that you're currently working on could change often, and it is a pain to move scripts to/from plugins whenever they become stable or not. The way we address this is to use Projeny (free open source project) which uses sym-links so moving directories to/from plugins is a super light operation.
Using symlink is interesting although it might now work for all versioning control systems. Which versioning control are you using ?
I'm too having that problem, and now it's okay for me.
I also have wondered if compilation time is slower for javascript than C#.
Yes, Javascript (UnityScript) compiles much more slowly than C#. In my tests, C# compiles at least 4X as fast as UnityScript, and in some cases up to 12.5X as fast.
I have been struggling with the same problem as you for the past two years and recently spent several weeks trying to work out how to improve compile times. There are two possible things you can do to drastically improve your compile times:
1) Convert your project to C#. Simply switching to C# cut my compile times to only 1/4 of what it was with US. (Went from 15s to 3.5s.)
Or 2) Split all your script files up into several groups and compile out DLLs so you only have to compile small parts of your program each time you compile. Or you can compile the most finished parts of your program into DLLs and continue working with loose scripts for your most recent additions. Unity will only have to compile a handful of scripts each time you compile. (If you choose to go route 2, this post of mine will show you all the steps required to get it working.)
I'm actually using a combination of 1 & 2 -- C# compiled into DLLs externally. When compiling a bunch of projects into DLLs (29 projects with 160+ script files), C# is 12.5X faster than Unityscript at compiling the whole solution. (Went from 44s to 3.5s.)
Script compilation time also depends on the loaded scene. When our Level Scene is loaded it takes about 25 seconds, when I load Menu Scene it takes 20, and when in an empty scene it takes about 12 seconds to compile. I believe all the scripts in the scene re-initiates or does some re-load that increases the compile time. I use Compile Time Tracker in GitHub to follow compilation times, I recommend that to everyone who wishes to track and improve script compilation times. https://github.com/DarrenTsung/DTCompileTimeTracker
After a compile, Unity has to deserialize and instantiate all objects in the scene again. This is the same thing that happens when you press Play or stop in the editor. If objects in the scene are linked to other objects in the project, the entire chain of objects must be deserialized when loaded. So if your scene contains an object that contains a list of prefabs for example, every single prefab linked must be deserialized when the scene is rebuilt. The extra time is essentially the amount of time it takes to load that scene file.
Perhaps you should consider investing in a more powerful computer. I don't know what specs you have on it, but I can say now matter how much you optimize a script or change it's compilation settings, a script will only compile as fast as your processor can go.
Thanks. I was hoping for a way to improve speed using the setup I already have, but getting more processing power would do it too. I have a $$anonymous$$acBook Pro 2.66GHz with 8GB ram. Getting a desktop machine would be a lot faster, but I'm not quite ready to make that investment.
Hi,
Try to make your code resuable and write DLLs so that you can easily import them whenever you need. This will increase the code compilation speed by 12 times. Compiling the scripts into DLLs require your code to be stable enough. Decision must be made before building whether a bunch of scripts can be independently handled and do not cause any issues after they're built into dlls.
Because if any error occurs in the dll code, that must be logged correctly to a log file or onto the console itself. Make sure you handle most common (at least) exceptions in dll scripts.
It is better to have a debug mode in your dll while you're testing. You can later disable it with just a single value change in a global c# script. This will let you know what has actually happened and where.
Of course, I agree with all above answers to make dlls and move your stable code in Unity's standard folders.
