Why does Roslyn run in-proc (in devenv.exe) and make the editor stutter by re-reading storage.ide when there's a syntax error - but not when there's no errors?

[daiplusplus]

(I'm not filing a bug report just yet - I want to eliminate a mis-configuration at my end first - especially because I'm unable to find other people reporting the same behaviour)

Repo steps:

1. Using VS 2019 Enterprise, 16.11.16, on Windows 10 Pro for Workstations 20H2 (19042.1706)
2. Have a solution comprised of these projects:

• Common.Data..csproj - targets only netstandard2.0, with <LangVersion>8.0</LangVersion><Nullable>enable</Nullable>
• Common..csproj - targets only netstandard2.0, with <LangVersion>8.0</LangVersion><Nullable>enable</Nullable>, and a project-reference to Common.Data.csproj.
• AnotherLibrary.csproj - multi-targets .NET Framework 4.8 and .NET Core 3.1
• OldWebProject.csproj - an old-school ASP.NET WebForms project targeting .NET Framework 4.8 (even with .aspx view files).

3. Create a simple POCO class in Common.csproj: a class with some properties and a constructor whatnot - so long as it's valid C# and compiles and VS is happy.
4. Add a // comment somewhere in the class: there should be no delay or stuttering in the UI thread or in the keyboard-typing-experience while you use your keyboard like a Steinway.
5. Add a new empty class or interface definition below that POCO class, and inside this new type's body define a member using only its type-name, i.e. public interface IThisMakesVSVerySlow { ObjectPool }
6. Observe that VS picks-up the invalid syntax and reports it in the Error List.
7. Go back to editing the comment from step 4 above, and just start keyboard-typing again into the comment: observe that VS severely stutters whenever any typing in the .cs editor - and disk IO activity rises significantly - even if you're editing something that shouldn't make the IDE read anything from disk, like editing comment text (and nothing that uses intellisense, or causes popups or the completion window to open).

So I fired-up procmon and logged all activity when editing that comment in a syntactically valid C# file, and again when I have that interface IThisMakesVSVerySlow causing the build error, and I saw that:

• When the .cs file is syntactically valid, then editor performance is good, and only ServiceHub.RoslynCodeAnalysisService.exe accesses the Roslyn\Cache\RemoteWorkspace\{id}\sqlite3\v2\storage.ide-shm, and storage.ide-wal files, and they're almost all WriteFile events.
  • ProcMon says:
    • 282 events for WriteFile to RemoteWorkspace\{id}\sqlite3\v2\storage.ide-wal (This is the Sqlite write-ahead-log, right?)
    • 100 events for WriteFile to RemoteWorkspace\{id}\sqlite3\v2\storage.ide-shm
• When the .cs file is syntactically invalid, then editor performance is horrible, and there is significantly more disk IO activity: procmon reports that on almost every keystroke devenv.exe (not ServiceHub.RoslynCodeAnalysisService.exe) re-reads from the C:\Users\Me\AppData\Local\Microsoft\VisualStudio\Roslyn\Cache\Host\{id}\sqlite3\v2\storage.ide file.
  • Note this is the Roslyn\Cache\Host directory, not the Roslyn\Cache\RemoteWorkspace directory, though the {id} string value is the same in both cases.
  • ProcMon says there was 11,610 ReadFile events - all for 4096-byte buffers (I assume this is just Sqlite reading 4KB-sized pages?), that's 47MB in total (my storage.ide file itself is 388MB, so it was reading through 12% of the file on every keypress - why?),

---

---

While procmon does show thread stack-traces for each logged event, I don't have symbols for devenv.exe, but here's a stack as reported by Procmon from one of the ReadFile events for devenv.exe:

---

• Why does this happen?
• Why does this happen in-proc for invalid files - and also block the UI thread and cause horrible editor typing jitter?
• Is anyone else experiencing this behaviour?

I have both procmon logs saved.

[CyrusNajmabadi]

@Jehoel please file a performance tract using the instructions here: https://github.com/dotnet/roslyn/blob/main/docs/wiki/Recording-performance-traces-with-PerfView.md

To answer your question, the storage system is a public API that many services use. Without the trace reported above, there is no way to determine which component may be at fault.

[CyrusNajmabadi]

Also, in vs 17.x versions we moved all Roslyn features that read from storage out of process. So if this is a Roslyn component doing this, it should not happen anymore. However, it may not be a Roslyn component causing the io, so we'll need a trace to diagnose things. Thanks!

[daiplusplus]

@CyrusNajmabadi As soon as you said "PerfView" my heart sank and my blood-pressure spiked. Can I borrow 5 minutes of your time in a Teams call sometime this week to make sure running PerfView goes as smoothly and correctly as possible? I can also repro the problem in a VM so could I send a VHD somewhere? or as a VM in Azure?

[CyrusNajmabadi]

@Jehoel You can just follow the instructions here. Thanks: https://github.com/dotnet/roslyn/blob/main/docs/wiki/Reporting-Visual-Studio-crashes-and-performance-issues.md