F#'s usage of ITextImage.GetText is causing large amount of data to get pushed onto LOH

[davkean]

Trace: https://developercommunity.visualstudio.com/content/problem/245786/slow-f-editing-experience-up-to-a-minute-until-typ.html

GC Rollup By Generation

Gen	Count	MaxPause	MaxPeak MB	Max AllocMB/sec	TotalPause	TotalAlloc MB	Alloc MB/MSec GC	Survived MB/MSec GC	MeanPause	Induced
ALL	5196	1,652.0	744.6	8,424.125	40,245.7	29,166.1	0.7	1.026	7.7	18
0	3869	886.0	744.6	8,424.125	14,865.1	20,456.4	0.5	0.083	3.8	0
1	1286	53.5	744.6	3,284.108	17,473.7	8,524.0	0.6	0.746	13.6	0
2	41	1,652.0	744.6	502.652	7,906.8	185.7	0.3	7.355	192.8	18

The F# stack above this doesn't make much sense to me, but our usage of ITextImage.GetText is causing 130 MB of data to pushed onto the LOH in the above trace.

[cartermp]

This is called in the following places:

• XML doc gen code (unlikely to be hit all of the time, but a possibility) https://github.com/Microsoft/visualfsharp/blob/fead0aac540485683f694524eadad79983ec28d9/vsintegration/src/FSharp.Editor/Commands/XmlDocCommandService.fs#L70

• F# CodeLens service (off by default, and getting line text, so unlikely) https://github.com/Microsoft/visualfsharp/blob/8ea71dd368401683fcbe895965c448c2688d3899/vsintegration/src/FSharp.Editor/CodeLens/FSharpCodeLensService.fs#L223 https://github.com/Microsoft/visualfsharp/blob/8ea71dd368401683fcbe895965c448c2688d3899/vsintegration/src/FSharp.Editor/CodeLens/FSharpCodeLensService.fs#L260

• Automatic brace completion (but only a small chunk, so also unlikely) https://github.com/Microsoft/visualfsharp/blob/fead0aac540485683f694524eadad79983ec28d9/vsintegration/src/FSharp.Editor/AutomaticCompletion/BraceCompletionSessionProvider.fs#L40

• GetFileContents in our language service bindings https://github.com/Microsoft/visualfsharp/blob/fead0aac540485683f694524eadad79983ec28d9/vsintegration/src/FSharp.Editor/Common/Vs.fs#L63-L65

Which is called in SetupNewTextView for out-of-project source files https://github.com/Microsoft/visualfsharp/blob/a58d9e6fc5e5499d808cd833af402521c757f23a/vsintegration/src/FSharp.Editor/LanguageService/LanguageService.fs#L282

And in SetupNewTextView for script files https://github.com/Microsoft/visualfsharp/blob/a58d9e6fc5e5499d808cd833af402521c757f23a/vsintegration/src/FSharp.Editor/LanguageService/LanguageService.fs#L289

My money is on these last two, and it seems that after @TIHan's work it may be resolved, since these calls no longer exist:L https://github.com/Microsoft/visualfsharp/blob/dev16.0/vsintegration/src/FSharp.Editor/LanguageService/LanguageService.fs#L221

[cartermp]

Saw this in another trace today, unfortunately our async implementation basically hides where this is coming from :(

[abelbraaksma]

@cartermp, the original trace above came from my machine and from the structure of the project I was working on, and the VS settings, may give some hints:

XML doc gen code (unlikely to be hit all of the time, but a possibility)

Slowness seems mostly caused by the deepest files (i.e., the common project use by everything else). This has the most dense code, relatively large source files and a significant amount of XML DOC comments (though they're mostly just /// comments without XML, I assume they go through the same renderer).

When editing these deep files, I often want to see the changes in the signature, so I'm hovering or ctrl-spacing for getting info tips. They typically appear only a minute or more later. Since for each tooltip the XML must be rendered as well, this may be a more likely candidate than it seems at first sight. Esp. if for rendering one tooltip, the whole assembly needs to be rendered; which I believe is the case.

A possible solution to this and many other parsing issues would be that a hash code of function + XML is maintained and only if the hash value of the XML string changes, the XML is rendered again. In 99 out of 100 cases, the XML and the signature remains the same for most functions (only the implementation changes), or the change is additive: a new function is added. In such cases, keeping a hash map could prove beneficial, but I can imagine this is not a light change.

F# CodeLens service (off by default, and getting line text, so unlikely)

The CodeLens was on during above trace. Though in my experience it isn't as heavy as the rest, it seems to only to source rendering and no full parsing + compiling. The question is, though, whether this keeps references of the lines, in which case this is definitely a candidate for improvement: after a change and rendering is finished, ideally references to strings should be released and GC'ed.

Automatic brace completion (but only a small chunk, so also unlikely)

I believe that when this trace was made, automatic brace completion was not part of the VS package yet (or was optional and I had it turned off). I would have to check to be sure, but I also agree that this is too rare to be of significant influence.

GetFileContents in our language service bindings
Which is called in SetupNewTextView for out-of-project source files

This project does not have out-of-project source files. There are a handful of linked source files (i.e., the AssemblyInfo.fs is shared through a project file link, and parts of it are overloaded), but I don't think that counts as out-of-project source files. There are a few xml and xslt files, but they are at the far end of the project and are rarely touched.

And in SetupNewTextView for script files

I assume you mean .fsx script files. This project has only three script files that have remained unchanged for a few years now. When I do scripting I use a temp project, simply because the main project is too slow to work with for quick scripting tasks or edit-copy-compile cycles.

Basically my main working mode is typing a lot of code by heart and ignoring the red squigglies that appear and stay far longer than that the code is actually invalid. I just visually check the code and check it in so that the build server can check it.

This is true for the deepest projects only, there's a significant difference when working on leaf projects (that are not depended on by other projects in the same solution). Also, I've cut my project in different solutions so that I can work on the common projects (the ones everything else depends on) without the rest being open. This helps so-so, and is often not a viable workaround. That said, recent updates to VS have improved editing experience (but bringing VS to an almost halt still happens regularly).

My money is on these last two, and it seems that after @TIHan's work it may be resolved

For this specific project I think that is unlikely but I am willing to make new traces with new VS versions if that's helpful. Also, I can share the project privately (with an NDA), or I can set up a remote session so we can have a look together at specific scenarios if that proves helpful.