New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VS 2019 tooling performance #6096

Open
cartermp opened this Issue Jan 14, 2019 · 4 comments

Comments

Projects
None yet
2 participants
@cartermp
Copy link
Collaborator

cartermp commented Jan 14, 2019

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 cartermp added this to the 16.0 milestone Jan 14, 2019

@cartermp

This comment has been minimized.

Copy link
Collaborator Author

cartermp commented Jan 18, 2019

#6084 is now completed, thanks @baronfel!

@cartermp

This comment has been minimized.

Copy link
Collaborator Author

cartermp commented Feb 1, 2019

#6076 is now completed.

@rojepp

This comment has been minimized.

Copy link
Contributor

rojepp commented Feb 1, 2019

@cartermp Make it a task list!

@cartermp

This comment has been minimized.

Copy link
Collaborator Author

cartermp commented Feb 5, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment