VS 2019 16.1 tooling performance #6265
Description
This is an overarching issue tracking F# tooling performance in VS 16.1. I expect these to positively impact other F# editors. Much of this work is actually in the compiler, as some things that are fine in a command-line scenario end up costing us dearly in a tooling scenario.
These are all filed based on data gathered from ETL traces with a solution loaded into Visual Studio, or are related to an issue where data was gathered in this way and determined to also be relevant. other issues labeled Tenet-Performance that are not listed here are not necessarily gathered in this way.
- Further possible fix to reduce memory usage #6390 Excessive creation of ILModuleReaders (for more than necessary for solution under measurement)
- Remove potential leaks when type providers are misauthored #6409 Remove potential leaks when type providers are misauthored
- ILVersionInfo accounts for 20MB in OOMed VS session #6403 ILVersionInfo accounts for 20MB in OOMed VS session
- Type providers get created hundreds of times causing large LOH allocations and UI delays inside VS #5929 - Type providers get created hundreds of times causing large LOH allocations and UI delays inside VS
- Remove use of reflecting into F# compiler in Type Provider SDK - try use ReferencedAssemblies fsprojects/FSharp.TypeProviders.SDK#305
- Read only the metadata when cracking binaries to reference in type providers - Read only metadata section fsprojects/FSharp.TypeProviders.SDK#284
- Cache cracked binary information in type providers and do so without a memory leak - clear reader cache in background to prevent leak fsprojects/FSharp.TypeProviders.SDK#295
- Removed reference counting from IncrementalBuilder; now relies on GC. #6863 - Remove reference counting from IncrementalBuilder and rely on the GC