Disable XMLDocCommandService due to UI delays

[cartermp]

See #6076

[dsyme]

What did the feature do (when it once worked)?

[cartermp]

XML doc generation via ///.

[abelbraaksma]

Does disabling this completely remove any parsing of ///, or is the text only parsing (as it's working now, ignoring any and all xml) still working? As that feature is rather invaluable to get useful tooltips of one's own function library.

[cartermp]

@abelbraaksma No, this is for generating boilerplate in code. It has nothing to do with QuickInfo, which is what shows in tooltips.

[TIHan]

I think this is 'ok' to disable for now. It currently doesn't work, which is a regression anyway.

This isn't a critical feature and based on @cartermp 's analysis it has the potential to cause UI delays. In that sense, it's fine disable it until we figure out a better solution/implementation that will not cause UI delay.

[cartermp]

In terms of how to implement this without causing big UI delays, we'd need to do something similar to what Roslyn does and work off of the SourceText that represents the document. At least with that we don't do a full allocation of the entire source file, which ends up on the LOH for large enough files, which ends up causing UI delays.

[abelbraaksma]

I'd wonder if it is possible if a task like this is required to hold the whole file contents to begin with. In essence, you'd need to find the doc comments (which are line comments) and one or two lines that follow them (the identifier).

What I am trying to say is: can't we use a streaming technique with a line-by-line read and only keep what we need to keep and discard the other lines? Wouldn't that possibly lead to a lot less GC2 collections and completely remove the LOH problem?

[cartermp]

SourceText from Roslyn is already (effectively) a chunked array that represents the source. The current implementation needs to change to use this data structure to generate boilerplate XML docs.