Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Reducing script compile time or a better workflow to reduce excessive recompiling

Discussion in 'Scripting' started by guavaman, Aug 20, 2012.

  1. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    6,294
    It'll be hard. But that kind of interdependence is generally a bad thing. You could look at this as the perfect opportunity to untangle your code!
     
  2. gfoot

    gfoot

    Joined:
    Jan 5, 2011
    Posts:
    550
    It could be a great time to get a trial of Resharper and learn how much it can help you sort out this kind of mess!
     
  3. JLJac

    JLJac

    Joined:
    Feb 18, 2014
    Posts:
    36
    Thank you for your answers! That's basically what I expected then. I'm probably too far in to turn back now (~2 years of work amounting to an almost finished game) but I will definitely take this wisdom with me to my next project. And I'll consider trying Resharper, it seems good for a bunch of stuff!
     
  4. guavaman

    guavaman

    Joined:
    Nov 20, 2009
    Posts:
    5,608
    Two assemblies cannot be co-dependent on each other. You cannot have circular references.

    For example:
    Assembly A (the Unity project)
    Assembly B (a DLL)
    Assembly C (a library both A and B need like UnityEngine)

    Assembly A can use classes defined in Assembly B, but Assembly B cannot use any classes defined in Assembly A. The same holds true for 2 DLLs. It's perfectly fine if both A and B reference C however.

    If you cannot untangle some of those interdependencies so you can separate some classes that can exist on their own in a DLL, the only solution you would have would be to move everything into a single DLL, which if you're still working on any of that code, would make it a lot more difficult to test and debug.

    Interfaces can help tremendously with interdependencies since both A and B can access interfaces defined either in A or in a 2nd DLL, D.
     
    Last edited: Jul 21, 2016
  5. JLJac

    JLJac

    Joined:
    Feb 18, 2014
    Posts:
    36
    Thanks for the extensive answer!

    When I did dip my toe in this, I had the problem that my partial projects (that I later hoped to convert to DLLs) didn't recognize the UnityEngine header. I wonder why that was, as the UnityEngine DLL was available in the project folder. Then I of course noticed that all of my partial projects had references to stuff in the other partial projects, which is the point where I realized this solution probably wasn't for me. But just out of curiosity I want to ask - do you have to manually attach DLLs (such as UnityEngine) to the partial projects? How do you get them to recognize for example UnityEngine? If so, is that also the same method you use to attach the DLLs you have yourself compiled to the next set of partial projects down the hierarchy?

    I'm aware that I could start to detangle my project - looking for classes that are self-sustained enough to be pre-compiled into a DLL and separate them out one by one. I think in my case that would not be worth it though - I'd be painstakingly buying back compile time a fraction of a second at a time, rather than the magic fix-all I was hoping for.

    In case anyone else is going through something similar, I'll state the alternate approaches I've come across researching. One that keeps coming up is simple but expensive - buy a really fast computer with an SSD memory. Another one is that there are compile speed-up softwares available for Visual Studio if you're using that (FASTBuild for example) but they're tricky and I haven't gotten any to work yet. The third possibility which I'm currently attempting is an ugly hack: make a clone of your project and gut it of everything but the most essential, then use that as an "incubator" for new features when going through the steps where compile time is most frustrating. When they're ready, move them over to the main project.
     
  6. guavaman

    guavaman

    Joined:
    Nov 20, 2009
    Posts:
    5,608
    I'm not sure what you mean by partial projects, but if you're making a DLL, you define references that the DLL requires. These references are links to other DLLs or other projects in the same solution. In the case of UnityEngine.dll, you point the reference to the UnityEngine.dll file in the Unity install folder. The DLL will then compile, and when you put it in the Unity project folder, it will find the UnityEngine.dll and work. If you add references to any other DLLs, they will have to also be moved somewhere into the Unity project folder.

    If you mean a new Unity project that only has some of your scripts added to it, those scripts would always have access to the UnityEngine library. If you're getting an error saying those UnityEngine classes could not be found, that's very odd, but since you didn't have all the required classes in the project to make it be able to compile anyway, I wouldn't worry about it.
     
  7. JLJac

    JLJac

    Joined:
    Feb 18, 2014
    Posts:
    36
    Maybe I'm misunderstanding, but isn't this basically what Unity is already doing by default?
     
  8. JLJac

    JLJac

    Joined:
    Feb 18, 2014
    Posts:
    36
    Ah yeah sorry, not really 100% on the terminology here ~ By "partial projects" I mean the projects sitting side by side inside the overarching solution. Basically the units that I later hoped to compile into separate DLLs. Talking about monodevelop/VS projects, not unity projects.

    Basically I'm out on waaaaaaay too deep water here - this stuff is beyond my level as a programmer. But I think I basically got the info I needed: No circular references, they have to rely on each other in a linear hierarchy. Thank you for your patience :)
     
  9. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    6,294
    Unity puts your code in 12 (!) different dlls. Four for each of the supported languages (C#, UnityScript and Boo). The dll's are:

    Plugins: Everything in the Plugins folder, except:
    Plugins/Editor: Everything that's in a folder named "Editor" in the Plugins folder
    Default/Editor: Everything that's in a folder named "Editor" not in the plugins folder
    Default: Everything else (most things)

    A good starting point for shortening down compile times is to just move parts of the project into Plugins. Unity won't compile the Plugins code if there's been no changes there, so it'll have the same compile time results as putting stuff in a .dll, except when you build or change script define symbols or anything else that triggers all the code compiling.
     
    Novack likes this.
  10. guavaman

    guavaman

    Joined:
    Nov 20, 2009
    Posts:
    5,608
    Yes, so it wouldn't help unless the VS/MD compiler was faster than Unity's which I doubt.

    Ahh, well then the reason would be each project needs to have a reference to the UnityEngine.dll.

    Glad to help!
     
  11. guavaman

    guavaman

    Joined:
    Nov 20, 2009
    Posts:
    5,608
    This is a good, easy solution which is functionally equivalent to making a separate DLL, but it has the same limitations -- you can't have classes defined in your main scripts referenced from the scripts you move into Plugins, so it would require the same cleanup.
     
  12. kru

    kru

    Joined:
    Jan 19, 2013
    Posts:
    452
    I'm not certain that this is true any longer. Try a test.

    Create a fresh project.
    Create some boring C# script that lives outside of the plugins folder.
    Note the compile time (speedy).
    Now create a large (10k) number of classes in that project (I used a script to create Class0000, Class0001, ...), and put them in the plugins folder.
    Now edit your boring script file and note the compile time (slow).

    Whether those 10k classes are located in the plugins folder, or in the main project, your compile times when changing the boring file are the same, unusually high amount. If Unity wasn't compiling the plugins folder, then why is the compile time unusually high, even though nothing in the plugins folder is changing?

    (If anyone does this test, and experiences different results, I'd like to know!)
     
  13. kru

    kru

    Joined:
    Jan 19, 2013
    Posts:
    452
    Another bit of evidence towards the plugins folders always compiling is that the timestamp on the firstpass dlls in Library/ScriptAssemblies is the same as the others.
     
  14. laurentlavigne

    laurentlavigne

    Joined:
    Aug 16, 2012
    Posts:
    6,223
    That bug's been fixed in 5.4 b2, was plaguing even 5.3 hopefully added to the ginormous auto QA test :oops:
     
  15. xakzhong

    xakzhong

    Joined:
    Sep 25, 2014
    Posts:
    12
    I have written a plugin to do this job. It can switch your script between source code and dll without missing reference.
    https://www.assetstore.unity3d.com/en/#!/content/40370
    Hope it can help.