- Home /
How Can I Reduce Build Time for Script-Heavy Projects?
My current Unity project now has build times at around 4 hours (!!!). I had previously assumed by computer was underpowered or short of memory, but having just upgraded the machine I've seen little improvement.
Research on the internet suggests that scripts with non-private fields can cause problems, so I've been through my entire source base (over 1MB of code!) making as many things private as possible. Unfortunately that's had nowhere near enough impact. Most classes still have 3-5 public variables and the scale of the refactoring job needed to remove them would be vast (many weeks of work, at minimum). Even if I did, they'd only be replaced with public functions, which presumably isn't much better?
What can I do about this? I need to get my build times down since I'm approaching alpha release for the project and need to be able to iterate builds quickly. Or, failing that, at least not have to literally do them overnight!
A large chunk of buildtime could be texture and audio compression.
Useful to know, but... four HOURS?! Oh well, I'll experiment a bit more I suppose.
Yeah, scripts themselves are probably compiled relatively quickly. The biggest operations I've found so far are things like lightmapping etc.
The best thing you can do, really, is make sure all your textures and sounds are in the correct format/compression for the platform to begin with. You can avoid all the compression/conversion this way. Obviously, larger textures will take more RA$$anonymous$$ to process and will take longer.
I don't think its the scripts that add to your build time. As @meat5000 said it is most probably audio and texture compression.
If you have $$anonymous$$m license, I would suggest you look at getting a cache server. http://docs.unity3d.com/Documentation/$$anonymous$$anual/AssetCacheServer.html
Useful tips, thanks. Unfortunately I don't have a $$anonymous$$m license... there's just one of me!
@meat5000 - $$anonymous$$y target is Win/$$anonymous$$ac/Linux. Is there documentation anywhere on what format/compression to use to avoid recompression at build time?
Answer by bateleur · Sep 22, 2013 at 03:59 PM
Well, unlikely or not it turns out it is a Unity bug. Now submitted at: http://fogbugz.unity3d.com/default.asp?565266_qvm4ip3s7laeiasn
To reproduce it, open a new project with no assets. Create three scripts and remove all code from them. For two of the scripts, add one variable of the type implemented by each of the other two. For the third script, add 20 variables of each of the other types. The resulting project ought to build instantly, but actually takes ~30s.
I'll be so bold as to put in an answer here ..
there's no doubt you have some specific problem man.
In a word - there is no reason it should ever take that long - so there's some problem to find!!
+1
I worked on a project with around 200+ scripts and i have tons of public variables referencing eachother. I also have a lot of manager classes with public arrays which holds references to 30 - 50 assets each. The project is an Android and iOS project and the build time (only Unity build time) is around 3-4 $$anonymous$$utes but mainly because of the Asset packing / compression. The compile time is only a few sec.
I exclusively use C#, so it might be UnityScript problem, but i actually doubt that the number of public variables is the reason.
@Bunny83 - From what you say it sounds like it might be a UnityScript problem. Because in my case there isn't actually any doubt left - I removed literally ALL the assets and it had no perceptible impact. But cutting down the number of variables in the scripts referencing each other actually did solve the problem.
I love unityscript, but then, I love Chocomoo. it's a bummer the problem relates to U/S ... since it "all boils down to boo" (or whatever) it does seem hard to believe. For the record I have a number of $$anonymous$$A$$anonymous$$$$anonymous$$OTH proects tha are indeed unityscript, as well as c#, and never also seen such a woe.
it's tonight's mystery puzzle.
Fascinating .. and fair enough on the unlikely .. but look, 30seconds is not 10 hours, you think this is what caused your problem?
In short can you now work around your problem and enjoy normal build times? I've been worrying about this all weekend on your behalf :)
What's the exact picture in your icon do you know? i collect old masters
30s is indeed not 10h, but these are empty scripts. Other tests suggest it operates like a multiplier to the build time.
The language is u/s.
(The picture in my icon is Leon Brunin's "The Alchemist".)
Answer by Bunny83 · Sep 22, 2013 at 07:45 PM
I've tried it again and yes, if i have a circular dependency (which is quite unusual) the building takes around 90 seconds. However only without pragma strict. I've done the same test with pragma strict and even in C# and the build time stays normal.
There's no reason to use scripts without pragma strict, it's even in new scripts by default and a recommended performance improvement
scripts without pragma strict allows you to write very unefficient code so you shouldn't complain in such a case.
i reckon Bunny has answered the question in a way.
ps pragma "script" ? :)
I agree that pragma strict is an excellent tool to prevent you from accidentally writing terrible code, but there isn't "no reason" to write scripts without it. It switches off dynamic typing, which is pretty annoying. (After all, why would you even have chosen UnityScript over C# if you didn't want that?)
In this case, though, all the variables are explicitly typed, so it absolutely is a bug unless dynamic typing is now deprecated (which AFAI$$anonymous$$ it isn't).
Sorry, but i don't see a bug here. In which way is Unity misbehaving? A long build time is not a bug. Have you ever compiled a moderate C++ program? A buildtime of several hours is normal for complex programs. The Unityscript compiler or the serializer just have a hard time without pragma strict and probably run into an infinite recursion (which is probably hard-stopped after some time / iterations).
Since it still builds your project without any errors there's no bug, just an inefficient compiler / build process.
btw: I never use UnityScript. I use C# exclusively. I don't think that most UnityScript users have chosen UnityScript because of dynamic typing but because they like or are familiar with the syntax.
I don't think that they will "fix" this behaviour since if you want a preformance boost you should use pragma strict. Also your bugreport (and this question) lacks of important information. For example that you're using UnityScript and not C# or Boo, so you might want to edit your question.
I added a 2048x1024 texture to my project today and it increased build time from 30 secs to 2 $$anonymous$$s! It's set to compressed.
Your answer
Follow this Question
Related Questions
Build runs slowly, editor game view fine 0 Answers
Updating Unity Caused Severe Drop in FPS 1 Answer
Distribute terrain in zones 3 Answers
Scripts optimisation 2 Answers
Which Unity functions are generally slow/bad for performance? 4 Answers