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

Improve this question
4
  • If someone would be so kind as to tag this for me with omnisharp, that would be much appreciated.
    – Bennett Keller
    Oct 2, 2017 at 15:11
  • 1
    What's the question here? Is it "how do I speed up omnisharp?"
    – zck
    Oct 2, 2017 at 15:47
  • Show us the (relevant part of the) actual profiler output.
    – Stefan
    Oct 2, 2017 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, 2017 at 16:02

1 Answer 1

Reset to default
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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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