Unity Incremental C# Compiler - deprecated

I know I will ask something probably out of the point but any concern on asmdef stuff ?
Cause since we switch from the old monolithic assembly-CSharp to our 30 asmdef small piece of code the reloading time when we change something or when we tried to open a script in Visual Studio takes just something like 10-20sec on Visual Studio he recompiles each project so I think it's why it takes so many times and that was faster before doing that.
P.S : If we ignore some weird issue where he recompiles every csproj multiple by the nomber of csproj.
For example sometimes (we have no idea why it is doing that but we have something like 30 * 30 csproj reimport :shrug: at this moment you can go take a coffee break or kill visual and start it again.

I know there is some dependancies between asmdef but woooh...
We don't link every assembly definition with every others so I can't figure out why we don't even have at least a little improvement in compilation time.

 

One major issue that facing with the incremental compiler is its inability to handle paths which contain special characters.

Is there somewhere I can submit a BUG report? Or could someone have a look into the issue?

 

To give you an update on making compilation time faster, having Incremental Compilation turned on didn't do anything. Instead, I fiddled with Assembly Definition files to reduce the compile time. I separated Unity 3rd party Assets from my codes into single folder since they don't need to change often. It reduced the Assembly-CSharp file size from 10MB to mear 200KB. It made big difference in the assembly file size but it didn't make much difference in compile time. From ~30s to about ~25s. It helps but not as much as I hoped.

I also tried to compare compilation time between 2018.2 and 2018.3. 2018.3 was faster by about 1s. I can hardly call that a "Significantly Faster"

Whatever Unity is doing, it never failed to disappoint in the past and it's safe to assume it will continue to do so how they are handling everything. And there are no remorse or apologies for wasting our time. When will they change?

IMHO, Unity shouldn't announce anything until it's ready for the release. First of all, it keeps our hopes high falsely. Having a beta version out is ok but having experimental version our early is such waste of our time. Given how poorly they execute, many falls under the deprecation traps; big announcement, few forum posts, lack of replies, no replies for a long time, and then silent deprecation. They are just worthy of making an announcement for the sake of announcement for Unite and nothing more.

The only thing that keeps me using Unity is because of C# and many useful 3rd party Assets. Without it, it would be long dead.

Unity will need to get their acts together fast and think from the Users perspectives, starting with how to make the Editor, Easy to Use instead of Simple to Use.

There are quite many low haning fruits, simple fixes that can help the usability and Unity should revisit them first before thinking about attempting another experimental project and I would really appreciate it if they could.

My two cent.

Cheers!

 

Does it mean that 2018.3 does not support C#7.0?

 

https://unity3d.com/unity/roadmap

C# 7 is part of 2018.3.

 

Experimental/preview versions are the ones you can play with, if you want, and give your feedback. They are not promises. Based on the feedback and the experience the Unity team gets, things may change and probably will. You don't have to spend your time on experimental versions. If you don't want to, just don't bother.

 

One of the things I really like about Unity is the very long roadmap they provide. Sure, they won't hit every goal they set for themselves, but the transparency is refreshing and exciting. It tells me that they're working on something, or at least intend to work on it. If some of the experimental stuff never makes it to a production release, it seems more likely because the Unity team ran into some insurmountable problem rather than just losing interest in the feature.

So just to make sure the Unity team is aware, I definitely appreciate knowing where you think Unity might end up in 1-2 years, even if it means occasionally being disappointed that a feature doesn't quite get there. Keep the experimental and feedback builds coming.

 

Just saw "deprecated" today. What does this imply? Can I still use asmdef files? Because we use those a lot!

 

asmdef should not be much affected.
But they are bad in my experience anyway

 

asmdefs are great in my experience

 

...So what the? This is deprecated with no warning or developer explanation ?

 

You got warring in the title.
Not that we are talking about finished product, are we? So is prone to evolve.

 

How so? asmdef are fantastic.

On topic, I haven't used IC in months anyway (basically since it become optional) so this doesn't really affect me but I'm not surprised; I found it caused more issues than it helped.

 

They reduced my productivity. They were always compiling, even they shouldn't. I even tried different folder structure, thinking that may be the issue. I know I am not alone on that wagon.
And any changes took even longer. So I ditched them

 

I see. So they haven't really fixed this issue. We are using Rider now to compensate for the long reload times. Asmdef were fine. It did improve our compile times. But if something better comes along, I'd be more than happy to try.

 

I feel like you must have set them up wrong then (-edit- or maybe they've improved a lot recently) as they should do the exact opposite.

My personal experience. This is my project, ~33000 lines of code.



I have a pretty old (6 years now?) cpu, 3570k so compile times are just bad in general.

If I make a single space change in the primary project (the one with 3400 lines of code) this is how long it takes me to recompile and load it in unity.



But if I remove the asmdef and make a single space and have to recompile the whole project again every time, this is how long it takes me.



* not scientifically timed, i just looked at the spinner.
** latest version of 2018.3b
*** I really need a new CPU

I would definitely love to be able to speed this up (outside of a new CPU). 14 seconds is a long time.

 

Don't know to be honest, since I haven't used them past few months. But don't expect so.

 

Maybe. I don't know. But I spent too much time on them already, trying figure out, what is wrong. So I am not going back.
I could fully agree, if I would be an isolated case. But otherwise ...

 

Nice one, hope that improvements continue without the Asmdef file requirement because many developers and indeed still a lot of 3rd party assets do not comply nor understand how to structure code dependencies and cannot use Asmdef for whatever reason.

Next year I hope for better assembly reload times

 

@Joachim_Ante It's interesting to see you recommending Asmdefs, specifically as a way to reduce compile time. While that might be technically true if you only look at compile time, increasing the number of Asmdefs in a project has a really terrible impact on the editor, causing it to lock up for many seconds at a time when performing common operations. Bug 1111543 includes a sample project showing a rather extreme case, but the gist is that with each additional assembly definition file, there's a worse-than-linear impact on the time it takes the Unity editor to do things like add scripts, rename scripts, move scripts, open scripts, etc. I'm curious if this is something the Unity team is generally aware of or concerned with? I had to stop using assembly definitions because of this, as merely having 30-40 Asmdefs in my project made the editor so sluggish that it dwarfed any pure compilation performance gains.

 

Hold.on. Let me check, if I understand correctly. Unity pushes VS as default tool to script editing. Yet from the quotation, I got impression, Unity team do not work with VS as default? Hence they will never notice the issue. Do I interprets this right?

Btw. In my case, I had turned of auto update. Since then, I always force update manually when needed with ctr+R in Unit. This helped a bit. But not solves genera lag issue.

 

Thank you.
I will then take my assumption that is working now.
But currently not keen to test again on my own skin.

 

@lukaszunity Thanks for the information, and the leads. Here are some findings.

I created a new test project, and set the External Editor to Notepad++ instead of VS. Double-clicking files opened them in Notepadd++ as expected, but I still noticed that Unity created .csproj files for each assembly. Maybe that's just standard Unity behavior? Or maybe there was something else I needed to do in order to completely isolate the Unity project from Visual Studio? In any case, this didn't change the behavior/performance.

My test case was to generate 200 AsmDefs in the project, and then see how long Unity "locked up" before it began compiling. With Notepad++ as the external editor, the behavior was the same as under VS: It consistently takes 38-39 seconds after adding a new script before Unity begins to compile. So, 38-39 seconds of being "locked up".

So then I updated VS. I had been on VS 2017 v15.8.8, and updated to v15.9.4. The results of my test case are much improved, so I believe you're right about there being some issue/s with VS Tools for Unity in older releases. While my test case originally resulted in 38-39 seconds of "lock up" when adding a new script, with an updated Visual Studio it's now between 12-13 seconds of lock up. Same goes for moving or renaming a script. Double-clicking to open it in VS used to also encounter the 38-39 seconds of lockup, but now double-clicking (assuming VS is already opened) appears to be instantaneous. That's very nice, since that's the most common of the actions I perform.

So, this seems pretty good. I'm tempted to drop the AsmDefs back into my real project again and see if the performance is reasonable there as well. I'm still not sure what Unity is doing for 12-13 seconds, and maybe that's as good as it can get.

Probably the biggest take-away from this is that VS Tools for Unity is tied to VS releases, and isn't independently updated. I didn't know that. I held off on a couple of VS updates because they didn't seem to offer anything I cared about, but I guess I'll start taking updates more often now.

Thanks again for the help. I'll reply to my FogBugz case with this information as well.

 

I profiled the editor, as suggested. I had to cut it down to 50 AsmDefs, as using 200 resulted in Unity running out of memory while profile the script add.

The first frame with significant wait time was about 18,000 ms in total. About 11,000 ms was taken up by PostprocessAllAssets:



The other ~5000 ms was in LocalCacheServer.Setup. However, this appears to be a one-time hit the first time I add script. When I profiled adding a second script, this wasn't taking up significant time.



And here's my cache server settings:

 

Thanks. I think the Cache Server setup stuff doesn't really matter, though. I think it's a one-time thing after starting up Unity, while the SolutionSynchronizer.ProjectSync runs every time I add a new script. The second time I profiled adding a script, SolutionSynchronizer.ProjectSync was 99% of the total time.

 

Im pretty sure I'm using them in 18.1.

 

Not from 2017.3b?
https://blogs.unity3d.com/ru/2017/1...assembly-definition-files-and-transform-tool/

 

Oh no, it such a pity you had remove Incremental compiler !

I finally acheived to have arround 10s with incremental compiler instead of 25s without it.
I'm using Unity 2018.4 and don't use assembly definition files (i have tried to use them but it's a mess with all dependecies to take care, the cycle dependencies problem...)

I have reinstalled Unity 2018.4 and i can't download Incremental compiler in package manager because you have removed it

Is there a manual installation (a zip file) to reinstall it again ?

Thanks

Eviral

 

Seams the main problem is a spaghetti code, of which you should take care. Tha advantage of packing into assembly, is to learn, how to organise and decouple your scripts, reducing, or eliminate circular references.

Regarding compiler, why forcing on using depreciate tools? In the end, we should see significant improvement, already without it. But however, if you really need it for any reason, just stick to unity version, which handles it.

 

I think you mean 2018.3.

Why? Now better IC is built-in part of 2018.3+:

 

Can you use it to compile runtime code?

 

The incremental compiler in unity has nothing to do with being able to do that.

You can compile code at runtime through many ways, and you were able to do that since forever.

For example, you can use mono's "evaluator" class (we used that in the past for our game as it was super comfortable).

Or you can add roslyn (aka 'Microsoft.CodeAnalysis.CSharp.Scripting') to your project to compile individual statements, or classes, or even whole projects at runtime.

 

I admit I'm not too clued up on adding libraries. I tried Nuget in Visual Studio and it added about 50 things (dependencies), and gave a whole load of Unity errors! I'm also trying to add the Mono API in my project by adding into my Assets, and that makes Unity not load, something to do with 'The editor layout could not be fully loaded, this can happen when the layout contains EditorWindows not available in this project'

 

How we do dat? I switched to 2018.3 haven't changed any settings in the preexisting project, and can't find anything about mono runtime in the settings.

Also, I hope asmdef files are working better with ECS than they used to.

 

Joachim wrote,

It shaved about a couple of seconds from half a minute from recompile. Better than nothing but I can't hardly call it significantly faster.


Joachim also wrote,

There are 10s of 1000s of Assets out there and how can you rely on Asset developers to write the code, the Unity-Way? Unity should've have prevented from it happening from the first place. For example, Assemblies shouldn't be reloaded every time it enters play mode unless the assembly has changed. It's a quick and dirty way to solve the problem. UnrealEngine support instant enter-play-mode no matter how big the project is and how badly user writes code.
I hope Unity makes it the highest priority. Unless they announce it on the roadmap, it will never make it out the door.

 

We've tried breaking our code base in asmdef files and got to roll it back - it was making iteration times much worse instead of improving it.

As some people mentioned already, looks like the compilation time gains are quickly offset by the time it takes to refresh/recompile dozens of projects inside the solution, which seems to happen to all projects even if you make a small change to a single file that has no impact on other assemblies.

When using asmdef files, VS got waaaay less responsive; attaching the debugger could fail sometimes (and work on a 2nd attempt) or take 10+s to happen. After deleting all asmdef files, things went back to normal: 10-15s to recompile our relatively small project, which isn't great but it's at least an issue we've grown used to in Unity.

I think any compilation time improvement will be pretty much useless until the whole Unity-VS integration is improved.

 

Did you delete the incremental compiler package from you project and asmdef in library?
As the topic say depreciated.

 

Yeah I did... Compilation times didn't change all that much (well, compilation + solution generation time), but the worst part was VS getting a lot less responsive, taking many seconds to respond again whenever I switched to Unity and then came back.

 

This can have a lot of reasons:
* slow laptop, pc
* not enough main ram,
* hdd full up, tmp folder to much content
* VS old versions, wrong net version, net broken, to many installed net versions sdks ( delete all VS/Unity and reinstall with unity only)
* OS swap file measured incorrectly
* Cleanup unused/old system files not fulfilled
* Any 32 bit OS version
* cpu does not switch into turbo > overheating
* etc etc..

 

This is more of a visual studio issue than unity / asmdef issue. If you use a different ide like rider it does not have the same issues. I have not tried vs19 yet but I'm hoping for some improvements in this area, not holding my breath though.

 

Yeah after many years of VS I'm switched to Rider last year, and for me it's better IDE.

 

https://blog.jetbrains.com/dotnet/2017/08/30/getting-started-rider-unity/

Is it also possible to rename variables or fields in rider, so all related fields or variables will be renamed and recompiled automatically like in VS?

 

Yes. Their refactoring capabilities are generally superior when compared to VS.

Rider's good. I've seen it break in epic ways less than in VS - not that it hasn't broken, mind you, but not nearly as often or as bad as VS. They also take your bug reports seriously, and fix the bugs you report in an open manner. Their Unity integration also moves a lot faster, so you'll get support for new Unity features faster than in VS.

 

@Baste's sentiment describes my experience. I'd also add if you wanted to play with new C# language features earlier, it was much easier to do so with rider than with VS. I was using VS code for a while and I still like it but Rider has the "Full IDE that's basically the same on all platforms" + all the Resharper bits and bobs.