abelbraaksma
commented
5 years ago but it's unclear how long it's been broken and if folks have even noticed.
I've noticed, and reported, I think two or so years ago, and vaguely remember @dsyme telling me at the time that it was a known bug and up for grabs. I'll try to locate the discussion. I've always missed it, esp since para doesn't work, and also because of a related issue leading to very wide tooltips if you have a few lines of doc comments (they become one very large, wide line, particularly unreadable on oblong screens).
Realising that a bunch of the performance issues were reported from my solution, it'll be interesting to investigate the impact of switching it off on that solution as well. Great find!
Using PerfWatson to check my UI delays, this was showing up as the number 2 source of UI delays:
Lots of delays >= 5s, with two at least 60s in length.
However, the feature doesn't appear to work, so we're paying the cost of it without benefiting at all.
This line may be the ultimately source:
https://github.com/Microsoft/visualfsharp/blob/9b55eccd1bc83ed123c5ae08c577be5646861830/vsintegration/src/FSharp.Editor/Commands/XmlDocCommandService.fs#L70
For large enough files this will allocate large strings on the Large Object Heap, which will eventually lead to long GC pause times.
The feature could be fixed, but it's unclear how long it's been broken and if folks have even noticed.
Even if it's fixed and works again, the UI delay issue won't get solved. So I recommend turning it off by default in options and then trying to fix it again, but doing so in a way that avoids allocating the contents of the file into a string.