I am a C# developer with many years of experience using Visual Studio (VS). Every time VS opens a project, it uses multithreading to load the project at full speed, and the CPU and hard disk usage are almost fully utilized.
C# is not Java, and I believe that its tool chain is fast enough and should not make users wait long enough to get a cup of coffee.
I am a Unity novice, and I have been wandering for many years before using Unity. Every time I open Unity to create a project, Unity always displays a progress bar, which can be as short as tens of seconds or as long as a few minutes. No matter which version of Unity, when I open the Windows Task Manager to check the CPU, hard disk, and graphics card usage, I find that their usage rates are very low, which makes me very confused. What is Unity doing when the progress bar appears?
These waiting times seem to be getting worse with the version of Unity.
Unity’s progress bar experience is very poor.
I hope that while Unity is displaying the progress bar, it can make full use of the CPU, hard disk, and graphics card, and at least one of them can be fully loaded and run at full speed, rather than letting users waste time, making the Unity experience worse and affecting the user’s mood.
So, what I want to say is that Unity has more than 5,000 employees worldwide. Why has such a simple problem lasted for several years without being fundamentally solved?
Such poor experience problems of Unity have been discussed in various communities, but do Unity’s 5,000+ employees have no ability to solve such problems?
No, they mostly depend on the project ie number of and types of assets.
Each Unity version has some variance in terms of initial project loading time but if you were to test this with the same project and open the project in different editor versions with a cleaned Library, and you actually measure it even with just a stopwatch, you’ll find the results will be much more varied.
You also need to consider that the initial project launch time is longer if the project is opened in a different editor version than the one it was last opened with. Same if you delete the Library folder to “clean” the project from cached artifacts. The second launch onwards it will have a relatively stable and faster loading speed.
A plethora of things. Check the editor.log for timing stats. This can help narrow down the culprit of a project opening slowly.
Also consider outside factors like antivirus (always exclude Unity projects from live scans) and system specs obviously. Running low on memory, a crippling HDD, or a mobile CPU/GPU can all contribute much more to Unity being slow than most other applications as Unity is a much more demanding tool than Visual Studio for instance.
Just compare between Unity2018 and Unity2022 if you want to see what OP means.
It’s absolutely stunning the slowdown, on the same exact system.
Go ahead, test it yourself.
I am NOT talking about the upgrade time and how it constantly re-adds crapware like the 2018-era Advertising package (WHY!!!) and analytics and NUnit and every other barfage that I have to stop, go back and remove from my manifest.json and then reopen.
I won’t even get into how fast Unity5 comes up. It will make you cry.
I actually did test every major version from 2017 to 2022 with two projects (actual work project and artificial project).
The results for the repeated launch time and script recompilation were consecutively getting slower from 2017, 2018 to 2019 which also remained the slowest of all three. 2020 was noticably faster, 2021 slightly slower again, and 2022 was significantly faster by a huge margin.
Others refuted these results but nobody could back it up with actual measurements. We have to consider that the introduction of the progress bar led everyone to subjectively feel that 2019 is still the fastest Unity version, whereas in my tests it was slowest by a notable margin.
I recall this from memory though, can’t find my own source.
I should also note that I started with projects originally made with 2017 to avoid measuring an uneven number of packages installed.
Well, you could say Unity does a lot of work. But in doing that work, it uses the CPU, disk, and even the graphics card very inefficiently. I guess I can understand that Unity is actually using the hardware very badly? And can Unity make significant improvements to this?
If you create a URP example project, you will see that Unity will wait for 2-3 minutes. I think this process should be optimized to only take 5 seconds. But it takes 30 times longer.
by the way, the compatibility between different versions of Unity is also poor. When opening Unity projects with different versions of editors, many errors will occur, and the corresponding errors will be reported multiple times by Unity. The error information display is not good, and the automation of converting old projects is not enough, often with a lot of errors.
For example: In Unity2020, I opened an official 2d sample project and was prompted to install ProBuilder, but no matter how I operated, PackageManger could not display ProBuilder after selecting the Unity-Registry filter until I accidentally clicked the refresh button (obviously, this may be when Unity first loaded the plug-in list, it was not fully loaded until I accidentally touched the refresh button below to solve the problem).
Such small experience problems obviously require users who are very familiar with Unity to successfully eliminate them.
In contrast, VS has much better forward compatibility.
At Last:
Regardless of whether you will improve Unity (probably not, after all, this matter is not a high priority).
Thanks for listening to my complaints.
When I create a new project it will be loaded in well under a minute, and if I open it again it’ll be loaded within a few seconds.
You need to be specific. Of course newer versions may introduce breaking changes in scripts leading to compile errors, although most of it will be auto-converted. More likely the bigger the jump.
If you open a project with an older editor version, this is not supported and can irrevocably destroy your project even. At a minimum it is required to delete the Library folder and have a backup.
If you keep opening the same project in different editor versions you’re doing yourself a disservice and errors are likely to occur. There’s only one upgrade path and that is upwards.
That sounds like a broken install or something else being wrong on your system.
