VS 16.x tooling performance

[cartermp]

This is an overarching issue that we're u sing to track F# tooling performance in VS. 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.

• Byte array LOH allocations using ByteBuffer #7982 - Byte array LOH allocations using ByteBuffer
• Use of CSVProvider with inferRows leads to UI delays #6646 - Use of CSVProvider with inferRows leads to UI delays
• Chunk large ResizeArrays in TcResultsSinkImpl so that they aren't promoted to the Large Object Heap #6127 - Chunk large ResizeArrays in TcResultsSinkImpl so that they aren't promoted to the Large Object Heap
• FSharp.Interactive.Session.bufferEvent causing UI delays that are 5 > x >= 2 seconds #6077 - FSharp.Interactive.Session.bufferEvent causing UI delays that are 5 > x >= 2 seconds
• Boxing occurs when hashing a range - 200+ MB over a 90 seconds of normal IDE usage #6052 - Boxing occurs when hashing a range - 200+ MB over a 90 seconds of normal IDE usage
• Lots of allocations and time spent in LexFilter #6006 - Lots of allocations and time spent in LexFilter
• GetMemberTypeInFSharpForm produces indirectly produces a large amount of Tuple instantiations causing UI delays in VS #5938 - GetMemberTypeInFSharpForm produces indirectly produces a large amount of Tuple instantiations causing UI delays in VS
• F#'s usage of ITextImage.GetText is causing large amount of data to get pushed onto LOH #5934 - F#'s usage of ITextImage.GetText is causing large amount of data to get pushed onto LOH
• RawFSharpAssemblyDataBackedByLanguageService produces large amount of data both in Gen1 and LOH causing UI delays in VS #5933 - RawFSharpAssemblyDataBackedByLanguageService produces large amount of data both in Gen1 and LOH causing UI delays in VS
• Type providers allocate large unshared assembly metadata that ends up on LOH #5931 - Type providers allocate large unshared assembly metadata that ends up on LOH

[cartermp]

Closing this out now that we have a pretty good hold on VS tooling perf. Still work to do, but boy is it a whole lot better.