Tried updating project to latest 2023 Unity from 2021. And, for some reason, Package Manager’s requests takes forever to process here
They do complete eventually, but it may take, like, 10-15 minutes. Every time.
To make it worse, I do Client.List offline request for our internal package manager, and it won’t respond as well.
Was using 2021.3.39f1 before, and it still works just fine there.
For more info, I couldn’t reproduce it in an empty/minumal project. Not sure what may be causing it, but UnityRegistry sure refused to load. And, overall, 2023 kinda loves to randomly freeze during loading. Have to kil the process and restart constantly.
Did you try delete the Library? This is generally recommendable when upgrading editor versions.
I would also try and delete the package cache location to ensure packages are redownloaded and to minimize the cache overall. Be sure to have at least 20+ gigs free disk space on the OS drive and the project drive.
Yes, I did try to cleanup everything. Didn’t help.
It also frozen 2 times during loading after that: once during Initial database reference, other after it loaded and started resolving packages again.
Anything in the editor.log that may point to an issue?
You could try dissect your project, remove packages and assets you don’t need. Or just doing so temporarily to catch the one that might cause the delay, there’s always a possibility that an editor script may not be perfectly compatible with 2023 doing too much work. Deep profiling could reveal if that were the case.
That’s definitely not normal. From the upm.log file, it does show that the issue is in the Unity Package Manager and not in the Editor. I suggest you turn on Debug logging (Preferences > General tab > Package Manager Log Level drop-down, choose Debug), reproduce the issue, then use the Report a Bug functionality. That could help figuring out what’s the sequence of operations that resulted in this.
Recored logs in the broken project, and in a small new project.
There is sure a lot of “Could not find cached metadata for package” for our internal packages. We got, like, over 100 of them in each project.
My guess is that Unity tries to do some expensive operations on those packages for some reason, then fails. And shear amount of them makes everything super slow.
I see there’s a very large number of List and SearchAll requests done at the same time. I know some are triggered implicitly by the Editor itself (probably too many, we’ll need to look into that).
Do you use a lot of embedded or local packages? For instance, all the com.foranj.* packages, or the org.nuget.* packages. I see it’s trying to look up com.foranj.* packages on the main Unity registry, where they’re not found. The large number of requests seem to be why in part why it’s so long (which, in turn, might be due to an increase in the number of List/SearchAll requests).
Please report this issue as a bug, it’s clearly a performance regression. I’ll also make sure we track this on our end, since it seems like it’s the result of a combination of multiple factors.
This project has 1 nuget package and 154 git packages. 7 of those packages are embeded for fixes.
We got our own package manager to install/remove/embed/commit changes to our internal git server.
No idea why it’s looking in Unity registry for them.
And yes, I’ll report it tomorrow then. Can’t attach an example project though.
No need for an example project, just the report from a project where you did the repro so we get the log file itself as “evidence” of what’s happening.
Did you configure a scoped registry? Or are you using a different approach, like installing your packages to the Packages folder directly?
One of the issues is that List will look at all packages currently in the project and query the matching registry (normally, https://packages.unity.com, but overridable for some package scopes via a scoped registry configuration). Unfortunately it does this for all packages, including packages that were installed from Git or that are just present locally, to allow users to use the UI to replace a local/git dependency with a version pulled from the registry. Now this might be the wrong approach especially in projects with a large number of non-registry packages like yours, so this could be redesigned to optimize the List request by implementing a different workflow for the UI.
I install packages by git url. There were no scoped registries feature back then.
When I need to make a modification - I move that package to Packages folder and initialize git in that folder. After doing changes, I commit changes to the server, update manifest.json to use new version, and delete the package from Packages folder.
@anon30979860
Hello again. Can you confirm something if possible?
We were looking to finally update to Unity 6 from 2021, and this package issue became an issue once again. So, I was testing how things are now. Results from my tests:
Client.List now executes in ~1 minute. I think it got faster - not sure what happened exactly. Still much worse than in 2021 though. Were there some optimizations in Unity 6 or somewhere else? In the bug report they said it can’t be fixed right away.
We’ve tried setting up an UPM server, assuming it may be faster. But no, it executes maybe just a tiny bit faster than using git. Is there no meaning in using it over git?
When using UPM, offline version of Client.List randomly unable to resolve packages, saying “package ### cannont be found”. Sounds like a bug. It does happen rarely in online mode too.
After recompiling, Client.List taks about 1 minute. But next executions are around 10-15 seconds - close to what it was in 2021. Is it some sort of caching issue?
Not sure if connected, but seems like “Initial Database Refresh” takes ages with Unity 6. Maybe half an hour, when it was just few minutes before.
Does it mean Unity just can’t handle large number of packages in general? We got exactly 200 packages in the project, including Unity ones.
I’ve attached logs. Ones starting with “upm” are when using UPM packages, one starting with “git” - when using git packages. ‘after_recompile’ - logs that are generated after I just recompile some random script. ‘during_import’ - when I imported project after deleting ‘library’ folder.
Some more info on this. Tested it with Unity 6000.1.0b1
It still hangs for long time on Initial Database Refresh.
BUT
If I just kill the process when it reaches Initial Database Refresh and restart the Unity - it completes it instantly the next time and finishes loading properly. Not sure if it is also true for older Unity versions, but it sounds like some internal cache or memory leak issue now that the fix is like that.
And some more info after tests.
I moved all 150 packages to Packages folder, then removed all dependencies from their package.json.
Results:
Resolving Packages took few seconds instead of a minute
Initial Database Refresh took 2 minutes instead of 1 hour
I feel like package resolving generates some garbage events that are resolved during Initial Database Refresh or something. Less dependencies - less garbage.