How to clean up unused "using" directives and assets/resources to speed up Unity?

I've been working on my game for about 6 months now and the Unity interface has started to crawl. It takes a good 1-2 minutes on my MacBook Pro each time I switch from MonoDevelop to Unity before the changes are detected and recompiled. First nothing happens for 20 seconds, then the scanning dialog appears, and then the interface hangs for about a minute. This is a terribly frustrating process, making it hard to reason about when changes have been applied.

I've been doing a lot of experimentation with different approaches, plugins, etc. I'm afraid that my "using" directives in C# scripts have not been at all cleaned up (I'm sure I have plenty of unused "using" statements). The same also goes for example assets etc. imported by plugins that I'm not making use of. Could these things be contributing to the slowness? If so, how can I go about cleaning this up? Failing that, is there some console log or output I can read to tell me about where Unity is spending all this time so I can try to isolate the problematic parts?

Sorry if this has been answered; I promise I tried to search first, but failed.

 

So unused using-directives should definitely not be an issue. The compiler should strip them out, and with how c# compilation works, an include shouldn't really extend the compilation time (unlike headers in c++).

Assets should also not be an issue, they shouldn't be reimported by code changes. The only thing that should happen if you switch is that the assemblies you have changed code in should be re-compiled.

Note that UnityScript is several times slower to compile than C# (as if there wasn't already enough issues with the language). Are you using that?

This sounds like a big problem. You should probably send a bug report with your project!

 

Thanks for the insight, Baste! Glad to know that the compiler is taking care of assets & includes intelligently.

I'm using C#, not UnityScript. AFAIK pretty much all my plugins are, too. I'm inclined to guess that the plugins are doing silly stuff during the recompilation process though. A couple of them have editor window integrations, etc. which I know are looking for asset changes. So, if there's any way I could look through some Unity logs about what's happening during this time it'd help me a lot!

 

You could try to turn on editor profiling in the profiler, and see what happens.

If you've got plugins that kick in when assets are changed, that might be an AssetPostprocessor, or a subscription to some built-in callback, maybe DidReloadScripts, though I'm not sure exactly when that kicks off. If the profiler doesn't show anything, you could try those.

It might just be that you have plugins that are really slow to compile - maybe they do some code-gen or whatever. Be sure to put all of the plugins in the plugins folder. The stuff in plugins is compiled in it's own step, which comes before the main compilation. This has two effects:
- other scripts can't see scripts in plugins
- when you only change scripts outside of plugins, the plugins assembly is not re-compiled.

 

Maybe you should check the editor logs and see what the editor is doing at start up. Everytime you start the editor, a log file is created (or replaced) and every action is logged. Some actions mention a timestamp, other have durations in ms and some have nothing But maybe you have luck.

 

Ah-hah! A .dll had snuck its way into the root, outside the Plugins folder. Moving it sped things up a LOT.

One point of clarification: I have other assets installed from the Unity Asset Store which have DLLs in them, like Rewired and Inventory Pro. I let these just install their contents from the package at the default location, meaning that I have DLLs like this:

• /Assets/Rewired/Internal/Libraries/Runtime/Rewired_Core.dll
• /Assets/Devdog/Internal/Devdog.Internal.dll
• /Assets/codeandweb.com/Editor/TexturePackerImporter.dll

I don't see any suggestion on the Unity folder page that these Internal folders have special treatment. Should I move these packages into the Plugins directory, or are they safe where they are?

 

It's really bad practice by plugin developers to put the default install location outside of plugins!

For future reference. the best way to handle that is import the plugin package to an empty project, move everything into a plugins folder, re-pack it as an asset, and then import that to your main project. You really don't want those things to be mixed with your main code.

For now, moving the .dlls to plugins shouldn't do anything. I'm surprised that moving the first one to plugins had an effect on compilation time. I'm blank on what's happening there - .dlls are pre-compiled code, after all. Maybe there was code in there that caused your main code's compilation to have to do a bunch of name resolution? idk.

 

I've been wondering about this! Especially the exact semantics of what constitutes a "plugin." Is any asset downloaded from the store a Plugin? I mean, image bundles aren't plugins. What about assets that are pure C# scripts, no DLLs?

I'm going to try to move everything into Plugins if I can.

 

@inZania You should check the Unity special folders to understand what should be in the "Plugins" folder. That has not necessarily something to do with plugins per se.

 

I have indeed read that page, but I remain confused. Specifically, the page which defines a Plugin states:

In Unity, you normally use scripts to create functionality but you can also include code created outside Unity in the form of a Plugin. There are two kinds of plugins you can use in Unity: Managed plugins and Native plugins.​

It continues in more detail, but the gist of it is that both flavors are DLLs (or, really, any precompiled code). However, many "asset store downloads" blur the line. If I download an asset from the asset store and it contains a DLL and 100x C# files... what is it? Maybe it's inappropriate to consider the entire bundle "one thing," but this makes it confusing about how I should proceed. Does the whole thing belong in the Plugins folder? Or should I just drag and drop the DLLs out of the default folder into my Plugins folder?

Baste suggested an approach with a new project and repacking it. This seems interesting, but I'm trying to understand the principles underneath it.

 

Managed plugin
If you write your own code into a DLL and put it into the Plugins folder, so you can get access from your Unity project scripts. This could be handy, if you want to strictly seperate data, logic and view classes from each other. But you could also add MonoBehaviour classes into a DLL, if you want to.

Native plugin
Platform specific code, like In App Purchase plugins. Those need also to be under the Plugins folder, more specific under the platform folders of the Plugins folder (i.e. "Plugins/iOS" or "Plugins/Android"). These files will be included into your build project (e.g. your xCode project for iOS), and includes native code (i.e. objective C scripts in case of iOS).

Hope I could shed some light