0

Getting a rather sizable speed issue with using go-to-definition from omnisharp. Ran the profiler, and received nearly 50% of the cpu time dedicated between:

isearch-printing-char

and

omnisharp-go-to-definition

The former was 9% larger than the latter. Anyone else experience this issue?

Modes I'm currently running on the buffers that are starting the function call:

C#, company, flychec, yas, projectile, ws

  • If someone would be so kind as to tag this for me with omnisharp, that would be much appreciated. – Bennett Keller Oct 2 '17 at 15:11
  • 1
    What's the question here? Is it "how do I speed up omnisharp?" – zck Oct 2 '17 at 15:47
  • Show us the (relevant part of the) actual profiler output. – Stefan Oct 2 '17 at 21:41
  • @zck the question was the performance issue with omnisharp's go-to-definition function. I posted in the question the profiler output that was relevant. isearch-printing-char consumed 650 cpu samples omnisharp-go-to-definition consumed 450 cpu samples. Although as I answered the question below, killing the isearch resolved the overall performance issue I was experiencing – Bennett Keller Oct 3 '17 at 16:02
0

On the second go around with go-to-definition, isearch-printing-char was removed. I may have either killed that command, or it was no longer needed. Uncertain, but with isearch-printing-char removed, the speed was returned to "fairly" normal for go-to-definition opening in the current buffer.

Current samples for omnisharp go-to-definition: 98 (down from around 500), and overall samples down from 1600 to 374.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.