2019.4 AssetDatabase V2 Refresh is Very Slow

[SomeGuy22]

After digging around I’ve seen that a few people have similar issues, although many of the fixes proposed haven’t helped in my case. When I first open Unity, everything will behave as expected, asset import times take about what they took in 2019.3 with my last project. But here in 2019.4, over time/occurring randomly I seem to get massive waiting times after making a single script change or file change in the assets. Deleting an empty .txt file even causes this sort of freeze for 30+ seconds when Unity is bugged, whereas when I restart Unity it will only take a few seconds.

For reference, I’m using 2019.4.14 with URP, and the Input System package as well as a few other default packages. The project is very tiny, only a handful of scripts and no assets aside from the example assets.

I managed to capture a few of these hold ups in the profiler. But first, here’s an example of what deleting a file looks like when Unity first starts:

As you can see, the time is only 3000 ms. Oddly enough, it looks pretty close to the “slow” version but with faster times. Really odd.

Here’s what deleting a file looks like when Unity bugs out over time:

30,000ms! This time, the SyntaxTree.VisualStudio.Unity.Bridge etc. seems to taking the biggest chunk. It’s jumped up to 75% whereas before it was 11%. What could be causing this sort of slowdown?? Both of these tests were performed by deleting an empty .txt file from the assets folder.

Finally, here’s an image showing the profiler for a freeze that happened after changing a script (1 line adjusted)

Seems to be split among the different parts of EndReloadAssembly, but still stemming from the AssetDatabase Refresh call.

I’ve tried a few fixes such as deleting some asmdef files and switching the Editor settings, but none really seemed to do anything. I’ll try to use the Editor Iteration Profiler and run more tests if it bugs out again, but this is seeming like a lost cause. Any ideas would be appreciated here. Script and file changes were never this slow on 2019.3 with a huge project (20+ GB) even that one also switched over to AssetDatabase V2. Perhaps something changed with 2019.4 or maybe because I started this project with URP or V2 from the start? Not sure at all

[Peter77]

@SomeGuy22

Here’s what deleting a file looks like when Unity bugs out over time

Deleting a .txt file causes SyncProject to be called 4 times for me, but 6 times in your screenshot, that’s strange that it differs. Maybe that’s the number of projects in the solution?

@SomeGuy22

What could be causing this sort of slowdown?? Both of these tests were performed by deleting an empty .txt file from the assets folder.

This happens every time you add or remove a file in Unity that is included in the C# project generation. You can specify what file types you want to have included in your C# projects in Project Settings > Editor > C# Project Generation, see “Additional extensions to include” and the image below:

Maybe your C# project and solution is quite big and complex? How many files are added to the C# project in Visual Studio? How many projects are added to the solution in Visual Studio?

I would also take a look at Preferences > External Tools and make sure Unity doesn’t generate .csproj files for packages where you don’t need to have the code in Visual Studio.

Regarding script changes that take long. There can be several causes for this. I recommend to use Unity’s Editor Iteration Profiler to find out where it spends the most time.

Things that often pop up when domain reloads get slow are [InitializeOnLoad] and [InitializeOnLoadMethod] usages for example. But the Iteration Profiler should find it.

You can also try a “Deep Profile” to measure where most time is spend after changing a script. Deep Profile can be significantly slower to capture, but often includes valuable information.

[SomeGuy22]

@Peter77

Deleting a .txt file causes SyncProject to be called 4 times for me, but 6 times in your screenshot, that’s strange that it differs. Maybe that’s the number of projects in the solution?

That’s a good catch! There are indeed 6 projects in the generated VS solution, however as you can see between the first and second screenshots there were always 6 calls. So that can’t be the source of the slowdown, but cutting down on those calls might improve the performance in general.

@Peter77

This happens every time you add or remove a file in Unity that is included in the C# project generation. You can specify what file types you want to have included in your C# projects in Project Settings > Editor > C# Project Generation, see “Additional extensions to include”

Ah, didn’t realize there were options for that. Could that be why file adjustments for .txts cause Visual Studio to do all that work?

@Peter77

How many files are added to the C# project in Visual Studio?

There’s only about 11 of my own .cs files so far and most of them are around a few hundred lines. But again I’m doubting that file count/solution size is really the source of the slowdown considering the performance is just fine when I start up Unity, it only worsens randomly over time for unknown reasons. Restarting seems to clear it up, as shown by the two screenshots.

@Peter77

How many projects are added to the solution in Visual Studio?

I would also take a look at Preferences > External Tools and make sure Unity doesn’t generate .csproj files for packages where you don’t need to have the code in Visual Studio.

There’s 6, and 4 of those are from a single package that I added. The project names seem to be based on the namespace given within the code(?) I didn’t realize we could adjust the generation of projects from within Unity! My settings are identical to your screenshot, which option would stop these extra projects from being generated? The package I included wasn’t added through the package manager, it was downloaded off the store and included in my Assets folder. I’m just speculating but if the namespace is determining project generation, would I have to change those namespaces? Or is one of those options generating projects when it finds a new namespace?

@Peter77

Regarding script changes that take long. There can be several causes for this. I recommend to use Unity’s Editor Iteration Profiler to find out where it spends the most time.

Things that often pop up when domain reloads get slow are [InitializeOnLoad] and [InitializeOnLoadMethod] usages for example. But the Iteration Profiler should find it.

Right, I saw the iteration profiler before and thought it might help with this. I’ll download it and report my findings if the issue pops again–it’s random after all so I have no clue when Unity will enter this bugged “extra slow” state. But it seems related to the file deletion issue. That is, when it’s slow to delete a file it’s also slow to compile, and when I restart both operations are as fast as I expect them to be. So it’s almost as though the whole Asset Database V2 becomes bugged and slows down both of these actions.

@Peter77

You can also try a “Deep Profile” to measure where most time is spend after changing a script. Deep Profile can be significantly slower to capture, but often includes valuable information.

I’ll try that as well if I encounter the bugged state.

Thanks for all the info, that was really helpful. I’ll keep trying to root out the issue, but it may be that it’ll just point to some random call within V2 and then I wouldn’t know where to go from there. I find V2 helpful due to improving my build times, but if it’s going to cause these slowdowns over time then I’m just not sure what the right approach. Restarting Unity all the time would be a pain, this is even the “LTS” version so I thought it would be a bit more stable. I know it’s hard to find some of these issues considering the vast amount of hardware out there, that’s why I’ll try to contribute as best I can if I can help narrow it down. And if it is unsolvable without a fix from Unity, hopefully they can patch it to the LTS quickly…

[Peter77]

@SomeGuy22

if it is unsolvable without a fix from Unity, hopefully they can patch it to the LTS quickly…

If you can’t solve it on your end, I recommend to submit a bug-report with your project attached, so they can use it reproduce the issue. They probably can’t fix such issues without being able to reproduce them.

If the project is bigger than lets say 1GB, my bug-report approach is like this:
https://discussions.unity.com/t/777806 page-3#post-6292514

[John_MSFT]

@Peter77 @SomeGuy22

This is no longer an issue in Unity 2021, and in Unity 2020 if you’re using the Visual Studio Editor package it will also not be an issue.

For Unity 2019.x, a bug report is a good step, especially if you can provide the project that reproduces this.

[SomeGuy22]

@John_MSFT

This is no longer an issue in Unity 2021, and in Unity 2020 if you’re using the Visual Studio Editor package it will also not be an issue.

Can you clarify a bit? What exactly isn’t an issue and why is it different in Unity 2020 and 2021? Are you talking about V2 performance degradation over time like I demonstrated in the screenshots?

As an update, I managed to find the bugged state again after leaving Unity on for about 6 hours and doing some work in my project. I’m not sure exactly what triggered it, all I did was make some more script changes and use the play mode a few times to test some stuff.

I already installed the Editor Iteration Profiler but it didn’t work… no results came up after hitting enable. Deep Profile for the Iteration Profiler also didn’t work:

I tried opening and closing it again, no luck. Maybe it’s a bug with URP? I did get a warning that said “Failed to insert item. Invalid menu handle” but I’m unsure if the iteration profiler caused it.

I did try the Deep Profiler for the regular Profiler and got these results from deleting a file:

Tracked it down to InternalEditorUtility.GetCompilationDefines(). There are 14 calls and it takes 28,000 ms which is a majority of the time spent waiting on the freeze. I also saved the profiler snapshot in case it’s helpful. The file is 1 GB though so I won’t upload it unless it can help in some way.

It took a while but I also captured script changes freezing in the Deep Profiler:

Here it looks like InitializeManagedCompilationPipeline and afterProcessingInitializeOnLoad.Invoke take up most of the time, 36,000 ms each. There’s also a LoadAssemblies item that takes some time, with LoadAssembly making 76 calls to file.read, perhaps these are the script files in my project. The actual read operation is 3 ms but LoadAssembly mysteriously takes up 18,000ms.

Maybe it’s just me but it seems like the common thread between all these points is the stuff at the bottom of this last screenshot. All of them seem to be related to “Compilation defines”/“Plugin Importer”/“Unity VS Support” etc. Even LoadAssembly calls the Compilation defines stuff. Here’s a final screenshot with the likely suspects:

Although it’s not getting stuck on the actual Compilation defines, etc. perhaps there is some hint that it is waiting on one of these items. Maybe related to the behavior of how it goes about using or getting the info they provide? Thoughts would be appreciated.

@Peter77

If you can’t solve it on your end, I recommend to submit a bug-report with your project attached, so they can use it reproduce the issue. They probably can’t fix such issues without being able to reproduce them.

I’ll also Archive my project just in case, but I really don’t want my reproduction example to be “wait for 6 hours with the project open for the chance to find this bug”. Unless that is a valid submission; I would assume there’s maybe a more practical trigger going on here that causes the slowdown?

[John_MSFT]

@SomeGuy22

Can you clarify a bit? What exactly isn’t an issue and why is it different in Unity 2020 and 2021?

Sorry for the confusion.

In Unity 2019.x, the Unity/VS integration is implemented differently than in 2020+ versions.

In 2020.x, users have the option to use the newer implementation of this integration with the Visual Studio Editor package. If that package is removed, then the fallback is to use the 2019.x (legacy) implementation.

In 2021, the legacy implementation is removed and only the Visual Studio Editor package is available.

If you’re using Unity 2020+, the Visual Studio Editor package is preferred and in 2021 it’s required for integration with VS.

The code paths shown in the screenshots are for the legacy implementation in 2019.

Were you experiencing these issues with 2020+?

[SomeGuy22]

@John_MSFT

Sorry for the confusion.

In Unity 2019.x, the Unity/VS integration is implemented differently than in 2020+ versions.

Thanks for the info, I see that the implementation for Refresh would be handled differently in 2020+, but does this new implementation actually solve any specific issues related to Asset Import/Compilation? For example, does it improve the slowdowns I’ve described when Unity enters this bugged-slow state after several hours of having the project open? If so, it seems like a very specific bug related to Database V2 and I’m wondering why it’s not fixed in 2019.

@John_MSFT

The code paths shown in the screenshots are for the legacy implementation in 2019.

Were you experiencing these issues with 2020+?

As I wrote in my first post, I’m using 2019.4 with URP. So no, I’m not using the new VS Package and from you’ve explained it seems like I don’t have that option if the package is for 2020+. Unity currently recommends the 2019 LTS version so the solution can’t just be to “switch to 2020”, although if it does fix the bug by handling Refresh differently it could be a clue that points to how to fix the built-in VS integration or V2 steps.

@John_MSFT

If you’re using Unity 2020+, the Visual Studio Editor package is preferred and in 2021 it’s required for integration with VS.

I’ll reiterate that the slowdown I’m experiencing is not just “general slowness”, it’s fine most of the time when I first start up Unity. But after a while is when these freezes occur which means there’s a specific bug/slowdown happening somewhere along the trail of V2 Refresh. Is there a bug report/improvement log for this 2020 VS package that specifically fixes this sort of issue from the old 2019 integration?

[John_MSFT]

@SomeGuy22

Unity currently recommends the 2019 LTS version so the solution can’t just be to “switch to 2020”

Sorry for the confusion. I wasn’t suggesting this - just making sure I didn’t miss something in your reports above and I was mistaken that you were talking about 2020. Thanks for clarifying!

@SomeGuy22

Is there a bug report/improvement log for this 2020 VS package that specifically fixes this sort of issue from the old 2019 integration?

Nothing public that I am aware of, unfortunately. That being said, the implementation details that avoid this issue in 2020+ with the package could be ported back to Unity 2019 (I think).

The best next step might be to file the bug so you can get notifications/track it. Please share the link with me and I can loop in the relevant stake holders who worked on this issue/package. Unity may have more details that I am unaware of too which could be shared on the bug report.

[Peter77]

@John_MSFT

The best next step might be to file the bug

File a bug at Unity or Microsoft?

[John_MSFT]

@Peter77

File a bug at Unity or Microsoft?

Through the Unity Editor.

[xoofx]

Could you try to send a repro to Unity bug report? We can more easily track it from there.

[SomeGuy22]

@xoofx

Could you try to send a repro to Unity bug report? We can more easily track it from there.

@John_MSFT

Through the Unity Editor.

Thanks for the suggestions. I stated earlier up in this thread that I was hesitant to make a reproduction example which included waiting for several hours and hoping for the random chance of this bug, especially if it was specific to my hardware. But regardless I’ve submitted it with the steps that should hopefully reproduce what I saw.

Actually, there was an issue with the Unity Hub bug reporter (as usual), I tried submitting it a few days ago and it failed. Then I re-tried and I got the checkmark saying it worked. However I didn’t receive an automated email response like I usually do, so I assumed it failed. I tried again today and got the email response, however checking FogBugz it seems the first one did go through but it never sent an email. So there might be a duplicate in the system now, sorry about that.

The two case numbers are 1299648 and 1300185. I’m not sure if either of them properly stored the 200 MB reproduction example, that may have been what caused the error. If one of them has the example project then you can safely close the other. Thanks for your help, let me know if I can clarify anything else.

[SomeGuy22]

I’ve finally tracked down a fix for this odd behavior, which I’ve posted in another thread. I’ll paste it here in case someone stumbles across this page instead:

I’m still not exactly certain what causes the issue in the first place but I believe I can say with some confidence now that updating Visual Studio 2017 seems to have solved the problem. Before I was using something around version 15.0 (I think build 26228.30), and when I did a manual update for VS 2017 it became version 15.9. I haven’t once encountered the problem since that update which was about a month ago. Except for one occasion where Play mode was still slow to start even after a few tries, yet I’m pretty sure the .txt file deletion times were as expected. So that might’ve been a different issue or just my HDD being slow which tends to happen sometimes. Restarting Unity fixed it and I haven’t experienced slow Play mode since then.

I guess there is just something about the older VS version which caused the Refresh to hang sometimes(?) although why it only happened after waiting with Unity open is a mystery still. As with versions of Unity I was also hesitant to update VS which might’ve broken my setup. Somehow I didn’t consider that VS 2017 still got patches and I wouldn’t be forced to go to 2019 or something like that. Updating from within VS went smoothly and even fixed up some other issues I was having with Unity like this problem . So I would recommend moving to a later patch if anyone experiences this slowdown. Hopefully that helps someone in the future! It was a pain to track down a fix but it ended up being pretty simple in the end.

I’m sure investigating the exact connection here might be helpful to improve Unity stability down the line, in the case something like this happens again. But with a solution for the end user available I would say it’s not as high of a priority, though I’ll let the Unity devs decide. Thanks again to everyone that weighed in and offered suggestions, it was a huge help and I’m extremely appreciative of the support!