Skip to content
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 16.x tooling performance #6866

Open
cartermp opened this issue May 25, 2019 · 0 comments
Open

VS 16.x tooling performance #6866

cartermp opened this issue May 25, 2019 · 0 comments

Comments

@cartermp
Copy link
Contributor

@cartermp cartermp commented May 25, 2019

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.

  • #8339 - Optimized find all refs and reduced memory usage in VS
  • #8234 - Using ArrayPool for AssocTable
  • #8021 - TcSymbolUses - significant memory consumption and allocations
  • #7982 - Byte array LOH allocations using ByteBuffer
  • #6791 - Add cache invalidation policy when a solution changes
  • #6646 - Use of CSVProvider with inferRows leads to UI delays
  • #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
  • #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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant
You can’t perform that action at this time.