Visual Studio 2019 IntelliSense really slow

[Slion]

Is it just me or IntelliSense does not cope well when generating entire modules.
In my case I had the following listed in NativeMethods.txt :

Hid.*
setupapi.*
Kernel32.*
User32.*

Makes typing any code frustratingly slow at times.
Would it be better if I moved all those exports in a dedicated NuGet package? Don't you guys already publish such NuGet packages?

Visual Studio 2022 seems to deal with that a bit better but not by far.

[AArnott]

Perf is an ongoing concern and one that we can certainly improve on. If you can use Report a Problem inside VS and indicate you have a perf concern and let it 'watch' you while you repro it, it will collect a perf trace so we can see just what's making it slow, to inform our efforts at improving performance. Be sure to drop a link to your feedback ticket here so I can ensure it gets routed to the right place.

Pre-built NuGet packages is something we're considering. In fact the https://github.com/dotnet/pinvoke repo may be replaced with code generated by CsWin32 eventually. But in the meantime, my recommendation is to not generate more APIs than you need. Whole modules is making your life slower than is likely necessary.

[Gavin-Williams]

I noticed this straight away when I started using CsWin32. Terrible performance. I've just upgraded my computer and it feels like Visual Studio is running on a single thread. Character display lags behind typing, some Intellisense operations take many seconds to complete. And I'm not using whole namespace imports. I'm using explicit method imports.

[AArnott]

Some results:

Milliseconds	Use
1600	Computing suggestions because something in NativeMethods.txt doesn't match any API. When you compile, do you see errors or warnings about this? Cleaning this up should speed things up a bit. We use fuzzy matching to make suggestions, which is expensive.
1600	Calling PEReaderExtensions.GetMetadataReader. We do this repeatedly and evidently it's an expensive operation. We might pool the result of this call instead of calling it for every code generation request.
1056	GetMethodsByName spends 472ms concatenating strings and another 399ms in 3 dictionary lookups per namespace in the search. We may be able to consolidate this to just 1 dictionary lookup with no string concatenation.
650	Generator.TryGetEnumName. I have a change to make this dramatically faster, but as this tends to execute when NativeMethods.txt contains something that ultimately will produce a warning or error, you could improve your experience now by resolving that.
511	SyntaxNode.GetText, which renders the syntax tree to a SourceText. Nothing we can really do about that until/unless we start caching and reusing SourceText, which is the ultimate in source generator caching and if implemented could save us much more time than just this.
183	TryGenerateConstant spends this much time in direct dictionary lookups (one lookup per namespace searched). We might be able to get this down to just one lookup.
183	TryGenerateType spends this much time in direct dictionary lookups (one lookup per namespace searched). We might be able to get this down to just one lookup.

That still leaves 9.8 seconds, so we're talking only incremental improvement here. Unless as part of the SourceText improvement we actually get to caching the SourceText, which would be a night-and-day improvement. I'll make some improvements today or file issues and add them to the table above to track those individual efforts.

[AArnott]

FYI @sharwell

[sharwell]

@AArnott we intentionally bypass the source generator execution on the inner typing loop (we assume the previous execution was correct and don't attempt to validate or update this assumption). The extension was overriding this fast path and causing the source generator to run. The fact that the source generator was running at all for classification indicated a bug.

[AArnott]

Good to know. @sharwell Do you think any of the items in my table are still worthwhile to fix? If we're talking an order of magnitude in excess SG executions, then I guess most/all these items become uninteresting.

[AArnott]

Perf work in the above table is now tracked in #612.