Perpetual 15-20% CPU Utilization from `ServiceHub.RoslynCodeAnalysisService.exe`

[vsfeedback]

This issue has been moved from a ticket on Developer Community.

---

Please see attached. I am seeing a perpetual CPU utilization from ServiceHub.RoslynCodeAnalysisService.exe. It appears as different stack from this issue: https://developercommunity.visualstudio.com/t/Perpetual-8-CPU-Utilization-from-Servi/10199236

---

Original Comments

Feedback Bot on 12/13/2022, 05:40 PM:

(private comment, text removed)

Feedback Bot on 12/14/2022, 06:17 AM:

(private comment, text removed)

---

Original Solutions

(no solutions)

[CyrusNajmabadi]

@Sam Harwell @Jason Malinowski

Ok. this seems very possible if the user just places their caret on something like object.ToString. We'll say "we need to highlight all those calls, and anything else that could be calling". Because it's on the topmost method, it could end up calling through any subclass of object and their override of ToString. So we search for all subclasses of types that the current project could be using. This is, of course, a potentially huge set. First, all the metadata symbols, and then all the source symbols as well in that project, or any project that depends on.

So this is working as it intended, just with awful perf.

The idea with FAR is that we determine the set of symbols of interest, and then go check all the potential matches to see if the are a 'hit' against any of those symbols of interest. This works well except when determining the set of symbols of interest is itself extremely expensive like so.

Once thing we could do instead is to really rethink how doc highlights work. Specifically, since we know we're only checking one doc, producing that entire set of symbols-of-interest can really through the perf equation out of whack. So instead, for doc-highlights, we invert things. We only walk the section of the doc that is visible, find the locations of interest (e.g. things with the same name), determine their symbols, then see if the symbols have a corresponding relation to the original symbol. So now we're never doing an initial walk of hte symbol hierarchy. instead, we're finding N potential hits in the file, and seeing if their symbols are an acceptable 'match' to the original symbol. We can, of course, cache this result as well.

This way we only pay the cost of walking inheritance for the K distinct symbols we hit in the file. This cost should be cheap as we only want 'unidirectional' hits. So we just have to walk up from teh match to see if it hits our start symobl, or walk up from our start symbol to see if it hits this symbol.

I'll see if i can make this work.

[Mike-E-angelo]

Thank you very very much for your efforts and diligence over there @CyrusNajmabadi + team. 🙏

Happy Holidays to you and yours. 🎅☃🎄