Definitely a rant, and shoutout. Been here for four years, and Unity somehow gotten worse.

Now, don’t get this solely as hate, but… come on… Unity, over the years, have become bloated, slower, and eventually painful to work with.

I know… I could do research to actually fix the bugs editor has on my own.
But thing is… the editor is just… “something” that likes to freeze. At random.
I can literally press Ctrl+S without changing anything, return to editor, and it just freezes, and keep on reloading assets till I kill the process. Sometimes it just crashes my whole system, or crashes at random occasions.

Batching? What is that, Editor asks. Quite literally, batching and occlusion has become non-existent.
No matter the settings, no matter whether instancing is on, off, whether it is occludee static & occluder setup, or full static, or even full dynamic, batching just does not work in any way. Not in built-in, not in HDRP.
And having 30k batches with less than 5k very low-poly objects is just mess.
I really don’t get how Unity got here.

It constantly logs me off, even during sessions.
Hub license keeps deleting itself, and I need to log in every single day I start a computer.
But that’s only scratching surface, and I am very upset, that this does not get fixed.
Yes, new rendering is very much important…
But tell me… is it really okay if editor threw errors out of the box? I start an empty project, open package manager, and boom, console is spammed with errors from EditorWindow, EditorUI stuff.
It has become PAINFUL to work with it.

I’m asking myself… how long it will take, if ever, till Unity decides to fix all the bugs, so the editor is maybe usable?

And please, don’t get me wrong. I love Unity for what it is and was. But it has become really bad over the years.
Just fix it. Please, fix it. This is not workable with.

7 Likes

yup 5.x was fastest, 2017-2018 were good, 2019 can be used… newer editors are too slow.

can also follow this thread (if not already there)

1 Like

One significant reason why newer Unity editor feels slower is how many components are C# now. While this can be a double edged sword, it definitely increases flexibility. My personal project for example would not be possible if the 2D animation system were “hardcoded” and not an editable package.

Editor speed really is not everything though. 2019 version looks and feels outdated to me already.

Errors are a whole different topic and I somehow doubt that was less an issue back then. We just forgot the time we had to spend on finding workarounds etc.

2 Likes

There’s a few editor things that bug me:

  • The Game window zoom percentage slider starts a few notches from the left when loading a project. Possibly fixed in 2022.

  • Sometimes trying to unfold a component in the inspector triggers a 5-10 second load/freeze, as if it wasn’t cached. Maybe they haven’t tested with slower RAM/HD.

  • Layouts are completely broken. Randomly the selected layout will go blank (the dropdown button), or you will get a console error about some window and have to reapply the layout.

  • New toolbar UX is much worse. They moved snapping which broke it, then fixed it, then moved vsync toggle which broke it while playing, and don’t the Global/Local and Pivot/Center use a dropdown menu now? Before they were one-click.

  • Packages window is so slow, especially if it defaults to selecting My Assets when you only wanted to see Unity Assets. You have to wait for it to finish loading useless data before the button enables.

  • It would be nice if Unity Hub wasn’t just a slow web browser (Electron).

3 Likes

This doesn’t seem to be the case in newer versions. In 2021.3 I can change my filters as it’s loading packages.

Barring unusual cases older software is always faster than newer software.

Or maybe they expect their paying customers to not be running out of date hardware.

1 Like

Kinda true and funny that this is the case. Wonder whether subconsciously we as devs often add as many features and are as sloppy in terms of optimization that we achieve what’s just barely bearable/good on current hardware.
Then 1-2 CPU generations later, that software feels fast.

I do always wonder about the hardware when extreme complains come up. In the end there just is a reason why companies usually equip their devs with top notch hardware (albeit in laptop form).

While bloat and technical debt are a real thing they’re only part of the picture. Newer technologies and techniques including ones aimed at increasing performance have higher minimum system requirements. AMD’s FSR 2.0 can be run on hardware from the Unity 5.x days but you would lose more from it’s overhead than you gained from using it.

Yeah it’s true, Unity will solve any issue for Accelerate customers with deep pockets but you’re completely on your own if you think it’ll become “democratised”.

Basically my advice is to test what the game needs up front, ahead of time. And don’t rely on anything at all that is WIP or not completely finished. Alternatively, scope the title small enough so that you can cope with replacing the features that don’t work in your use case.

Indies aren’t Unity’s target market vs military or advertising.

Or unavailable on the latest and newest hardware on 2/3 (the majority) of Unity’s pipelines, in new Unity.

Their main customers don’t need it, after all.

1 Like

Yeah I switched my example to FSR 2.0 which is available on the consoles.

And old hardware running new software is doubly slow. Naturally, if you want to use the latest software, the latest hardware is preferable.

I kind of want to know what hardware the peeps experiencing really long domain reload times are using, because even on my old i7 5960X, a cpu that was 8 years old when I replaced it, I was still only get ~5 second reloads on 2021.

1 Like

Worst I’ve seen is a few seconds in 2021.1 with a 130GB project (30GB assets plus 100GB library) with no assembly definitions. I’m on a 5950X w/ 64GB DDR4-3600 which is not dirt cheap but it’s not crazy expensive either.

is what’s in project total as important as what is in the scene though?

I had a project that was like 10gb total, but lots of instanced meshes in scene and it took ages to enter play mode. I don’t remember what version, 2019 or later. I probably was closer to min specs than the other end.

It was a fighting game. Just about everything including the majority of the code was in a single scene. Stages were stored in their own scene files but they were just static objects and lightmap data. Most menus were separate too but most of the code that they used was reused in the main scene.

I just looked up the current cost of these components. It’s $550 for the CPU and $200 for the RAM. I paid more than that but the majority of the difference was due to the pandemic.

@Ryiah
is most of that size coming from big textures, or something else?

A mixture of assets but primarily large textures.

For some reason, the whole “hold on, repainting this and that” doesn’t exist on my m1 mac - which has made me quite fond of using it for smaller projects. Its singlecore performance is also significantly fast than my ryzen 3600, very noticeable.

That said, I remember there was an alpha or beta version which reduced/removed the “hold on” - with compile times that where quite similar between the m1 and pc. Didn’t last.

Yes, especially in real game projects, with 5+ people contributing, unity 2020 and later got slower and slower and slower.

Unity 2022.1 takes the cake with a domain reload and no way to turn it off every time Rider autosaves a file. The play mode option to recompile after playing stopped is simply ignored, as well.

This is actually dangerous, I have domain reloads happening and code that I was just in the process of completing compiles AND EXECUTES, e.g. spawning some objects in an ExecuteAlways behaviour, and or in OnValidate code that’s not quite right, literally clobbering hundreds of assets.

But what really breaks the camel’s back opus the overall time I stare at "Hold on…,& Progress bars.
Every single day, I stare at them, waiting for gracious permission to make that one mouse click that would have completed the operation that ACTUALLY warranted the domain reload. (Which will trigger another one)

I have experimented with turning off auto refresh but I wish I could just let Rider trigger the refresh for me then. Manual is bad, often one ends up debugging the same code again and again breite realizing a refresh was needed for any changes to apply.

Conversely, Asset imports should be MUCH more forgiving, like with a 5 second grace period some can move files around or begin a Rename before the full blown asset importer kicks in.

Lastly, please please run some kind of linter that knows that only comments changed, and forego the recompile. Domain reloads from idempotent source code changes coming from writing the finishing documentation of a feature easily adds 10-20 minutes to the wrap up times.

2 Likes

I was extremely angry because Unity automatically compiled while I was typing code (Unity 2020 and later had this problem). So much so that I went to the Unity forum and created a thread cursing the psycho who made this feature -_-

Doesn’t disabling autosave in Rider work?