VS 2019 tooling performance

[cartermp]

This is an overarching issue that we're using 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.

• #6127 - Chunk large ResizeArrays in TcResultsSinkImpl so that they aren't promoted to the Large Object Heap
• #6077 - FSharp.Interactive.Session.bufferEvent causing UI delays that are 5 > x >= 2 seconds
• #6052 - Boxing occurs when hashing a range - 200+ MB over a 90 seconds of normal IDE usage
• #6044 - JaroWinkler string distance algorithm allocates 1.11 GB and spends 4.8% of CPU time generating suggestions that are rarely used
• #6006 - Lots of allocations and time spent in LexFilter
• #5938 - GetMemberTypeInFSharpForm produces indirectly produces a large amount of Tuple instantiations causing UI delays in VS
• #5934 - F#'s usage of ITextImage.GetText is causing large amount of data to get pushed onto LOH
• #5933 - RawFSharpAssemblyDataBackedByLanguageService produces large amount of data both in Gen1 and LOH causing UI delays in VS
• #5931 - Type providers allocate large unshared assembly metadata that ends up on LOH
• #5929 - Type providers get created hundreds of times causing large LOH allocations and UI delays inside VS
• #6076 - XMLDocCommandService doesn't work and is a notable source of UI delays in VS
• #6084 - TcSymbolUseData[] accounting for 19.1 MB on the LOH
• #6047 - Ranges allocate 670 MB in 94 seconds of normal IDE usage in service.fs only
• #6028 - Use smaller keys in language service caches
• #5937 - ParseOneInputFile allocates large amount of data on the LOH
• #5936 - Matching braces in large files cause a large amount of data to be pushed on LOH
• #5935 - Parsing a large file causes the char[] buffer behind it to be pushed onto LOH
• #5932 - Range.mkRange is allocating large amount of data normalizing strings
• #5922 - CheckFormatStrings.parseFormatStringInternal appears to split source files many times over causing LOH allocations
• #5560 - Codegen: String.Concat called multiple times for concats of 3 and 4 strings

[cartermp]

#6084 is now completed, thanks @baronfel!

[cartermp]

#6076 is now completed.

[rojepp]

@cartermp Make it a task list!

[cartermp]

#6044 is now completed, thanks @AviAvni and @forki (we'll still consider @forki's change separately).