it’s so slow in 21 that whenever I return on 2017 it feels like I upgraded my computer. And I’m talking about an upgrade of 6 generations of cpu. So if I used 2017 on my old i7 920 I’d still have a 2x faster spool time. This is bad.
time from press play to live is 2 second in 2017
in 2021 it is … drumroll … 9 seconds!
that’s a 4x increase in spool time!
repro with one empty scene and the same prefab which is a 50 triangle animated model
I’ve made similar experience with newer Unity releases, my disappointment is hidden under the spoiler in this post:
However, since Unity 2019.3 they have support to skip the domain reload when entering/exiting PlayMode, see this thread . This can be a huge time-saver, but it’s not just a switch that you can turn on, you need to make changes to your code base to make that feature work. But once done, using this feature can actually outperform Unity 4.6/2017.
“The editor performance worsened so much over time, that even new hardware isn’t able to outperform Unity 4.6 on a PC from 2008”
…
I just realized why we got so much done back in 2013, the engine allowed for very short iterations. And now I subscribe to the wisdom of staying on old versions of the engine, like Dyson Sphere Program using 2018.
Any explanation on what internals cause such decay? I know a team’s on performance and seen many huge improvement in asset loading, any news on seeing this fixed this year?
@laurentlavigne how many performance threads are you going to make? Why don’t you upgrade your computer?
That’s an interesting question, I think as many as needed, this is a beta forum after all and its function is to report bugs like this one. Unity prioritizes regressions. Also for those considering to jump to new versions, posts like mine redlining massive regressions might help make an educated decision. I sure wish I saw a post outlining this slowdown before I spent 2 days on this version.
As for your suggestion of upgrading hardware, I’ll give you the benefit of the doubt and assume that you’re not trolling. The answer is more complicated than just push the spend $2000 button (just to use a software!).
Compilation is already blazing fast and scales linearly with # of cores, thank the Gods for that, domain reloading is what’s 2x or 3x slower. From trying this out on a i9 10900 (which is fucking fast) compile time drops a lot but domain reloading doesn’t, my guess is that’s single threaded. Problem is there is no CPU that’s 4x faster than a 8400, the current work machine so upgrading only benefits marginally. Read peter77’s post if you want more numbers.
Obviously a work software shouldn’t require a massive expense in hardware in order to match the same iteration speed as before the 500ms announcement 
What’s better, letting Unity know about different performance regressions so they can fix them, or telling all Unity users to upgrade their computer(which doesn’t help much with some of the performance issues)?
Generally I’ve seen our editor performance, iteration, and build times get slower and slower 3.x > 4.x > 5.x > 2017 > 2018 > 2019… It’s not as easy as ‘just get a new computer’ for our team. Most Unity devs I talk to are experiencing the same thing too.
Blog posts, roadmaps, Unite talks etc. often hint at performance improvements that never quite seem to materialise in real gains for us.
Perhaps Unity need to dogfood their engine a bit more to feel some of the workflow pain points themselves. I don’t think tech demos that aren’t maintained are enough to hit all the rough edges that shipping devs hit on various platforms.
I was going to switch to this version then reality slapped some sense into me.
I had to run those benchmarks 3 times because I thought I made a mistake, even with the math reversed (old/new) it’s damning.
On the bright side, if I keep my 8400 and 2020.1 and next project downgrade to 2018.LTS I’ll feel like I bought a $1000 computer.