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.
The following list of issues are resolved and will be in VS 2019 GA. Further issues are tracked by #6265
- [x] #6044 - JaroWinkler string distance algorithm allocates 1.11 GB and spends 4.8% of CPU time generating suggestions that are rarely used
- [x] #6076 - XMLDocCommandService doesn't work and is a notable source of UI delays in VS
- [x] #6084 - TcSymbolUseData[] accounting for 19.1 MB on the LOH
- [x] #6047 - Ranges allocate 670 MB in 94 seconds of normal IDE usage in service.fs only
- [x] #6028 - Use smaller keys in language service caches
- [x] #5937 - ParseOneInputFile allocates large amount of data on the LOH
- [x] #5936 - Matching braces in large files cause a large amount of data to be pushed on LOH
- [x] #5935 - Parsing a large file causes the char[] buffer behind it to be pushed onto LOH
- [x] #5932 - Range.mkRange is allocating large amount of data normalizing strings
- [x] #5922 - CheckFormatStrings.parseFormatStringInternal appears to split source files many times over causing LOH allocations
- [x] #5560 - Codegen: String.Concat called multiple times for concats of 3 and 4 strings
Most helpful comment
@cartermp Make it a task list!