Frequent 4-second Editor Freeze, In And Out Of Play Mode, From Editorapplication.internal

I've been getting these incredible lags in the editor (currently using 2018.3.11, but it started with 2018.2.x) for months. I've only now been able to investigate its cause by profiling the editor:



It looks like the editor is calling File.Read() over and over and over (until it gets the return it's after, I presume), adding up to a 4 second freeze on a single frame, followed by another a few seconds later, and another, etc

This happens both in play mode and out of play mode, and is unrelated to game code, or even what I'm doing in the editor at the time. I don't understand what File.Read is after in these moments, as it happens completely randomly and unpredictably (I could simply be moving my mouse around, out of play mode, not clicking anything, and the editor will freeze dozens of times over the course of a a few minutes).

The random nature of it (and the fact that is doesn't happen to any of my teammates but happens to me on multiple computers) seems to point to it being related to whatever files the editor is after being locked by an external service. My suspicion is that, because I use OneDrive to sync my project files in real-time (this is a deal breaker, I don't want to hear "stop using OneDrive"), Unity can't get the files it needs as OneDrive tries to sync them. OneDrive is fairly conservative about accessing files if there's any sign another application is currently "using" them, but a Unity project is complicated enough to fool this process, I imagine.

However, that still doesn't fully explain it, as I can't imagine what files the editor is trying to access in these moments and why OneDrive couldn't simply sync them anyway (neither application is requesting write access to the file, as far as I know). How many read operations does the editor normally run in the background that this could come up even when I'm literally doing nothing in the editor?

About a year ago, a bug was introduced where projects stored locally in a OneDrive-synced folder couldn't be opened or used at all without tons of errors. It was fixed in a patch release. That bug was related to the use of absolute paths in the Package Mananger, so this is obviously different, but could this be a similar regression? Or, am I barking up the wrong tree entirely, where this has nothing to do with where on my hard drive my project is kept?

My current workaround is to "pause" file syncing while I'm working, but this is utterly unacceptable as a anything but a testing scenario, and I haven't yet been able to confirm it even as a temporary solution because the occurrence of the issue is so random (though when it does happen, it does not let up for several minutes).

 

Still investigating, but upon deep profiling I think I can narrow it down to the AssetBundleManager asset window! I'm the only one on our team who manages our AssetBundles, so I'm the only one who has that tab in my Editor layout, this would explain why it happens on all my machines.

Not definitive yet, but it seems to be the issue. I should have guessed this might be it, as there are a number of reports of just having the Animation/Animator windows (for example) visible causing problems...