nim-lang / nimsuggest

idetools for the nim language
MIT License
42 stars 9 forks source link

Huge performance drops when having larger libraries imported #55

Closed RSDuck closed 7 years ago

RSDuck commented 7 years ago

Having a larger library imported slows every nimsuggest action down. Also the quality of the suggestions decreases too, in some situations only local symbols are shown where previously the suggestion of global symbols worked fine.

E.g. when having SDL or OpenGL imported the performance degrades noticeable

Araq commented 7 years ago

Do you use 'nim devel'?

RSDuck commented 7 years ago

yes, I hope the issue doesn't sound too rude.

The problem is that nimsuggest just acts too slow in these situations. E.g. quering the signature of an often used OpenGL procedure(glGenBuffers) lasts around 7 seconds on my machine(which is a decent one).

Maybe you already have a masterplan to solve this problem, but I can't look into your head and maybe you didn't knew about this and that's why I made this issue.

Araq commented 7 years ago

For me recent nimsuggest is very responsive, even for large projects. I will try it with the OpenGL wrapper.

StefanSalewski commented 7 years ago

I have just done a short test. Latest Nim and Nimsuggest, installed opengl with nimble, tested with my patched NEd editor (due to latest nimsuggest chk format change). Test file was

$ cat h.nim 
import opengl

proc main =
  var b: ptr GLuint
  var i: GLsizei

  echo "entering main"
  glGenBuffers(i, b) # line X
  glGenBuffers(

main()

nimsuggest works basically fine, when I move cursor on glGenBuffers on line X I got the signature immediately, and when I go with cursor on that symbol in line X+1 and press "Ctrl p" I got that signature also immediately. Problem occurs, when I go on that symbol and press "Ctrl w" to open opengl.nim and jump to definition. Works also immediately, but after that problems occur: When I go back to the test file and press "Ctrl E" for error check, I got only this debug output:

>>> chk skUnknown       Hint    ??? -1  -1  "h [Processing]"    0
>>> chk skUnknown       Error   /tmp/hhh/h.nim  8   2   "undeclared identifier: \'glGenBuffers\'\x0AThis might be caused by a recursive module dependency: /home/stefan/.nimble/pkgs/opengl-1.1.0/opengl.nim imports /tmp/hhh/h.nim\x0A/tmp/hhh/h.nim imports /home/stefan/.nimble/pkgs/opengl-1.1.0/opengl.nim"    0
>>> chk skUnknown       Error   /tmp/hhh/h.nim  8   14  "attempting to call undeclared routine: \'glGenBuffers\'"   0
>>> chk skUnknown       Error   /tmp/hhh/h.nim  8   14  "expression \'glGenBuffers\' cannot be called"  0

That is really strange -- of course module opengl.nim does not import my test file h.nim. Unfortunately I have not yet an idea how to do a similar test from the command line. And I have never seen such behaviour with other modules like all the GTK3 related ones.

RSDuck commented 7 years ago

hm, in some situations it's indeed fast, but then it's slow again, here I made a gif to demonstrate how it varies: gif4

StefanSalewski commented 7 years ago

Maybe the problem is your editor?

You may try to reproduce the problem with nimsuggest started from the command line. That is some work, but makes it easier for Araq to fix it. Are you sure that your editor really uses latest version of nimsuggest? I think some editor plugins ship their own nimsuggest version. If it really uses the latest, then I wonder if chk (error check) commands works at all for you. Because output of socked communication string format for chk has recently changed -- I updated Nim and Nimsuggest yesterday from git and had to patch my check proc in my NEd editor to get chk command working again. (Other commands have not changed.)

RSDuck commented 7 years ago

I'm using VSCode together with bleeding edge Nim/nimsuggest from today. The extension uses the nimsuggest bundled with Nim, so that's not the problem.

I tried nimsuggest from the command line and it works immediately, while in the editor it needs several seconds to give results. Then I debugged the extension and seems like the extension itself isn't the problem. Maybe the library used for RPC communication faulty otherwise I couldn't explain what's going on.

RSDuck commented 7 years ago

It really seems to be a problem related to the RPC library the Nim VSCode language extension uses or to Nimsuggests EPC mode(probably not, see https://github.com/pragmagic/vscode-nim/issues/44 for more).

I close this issue, it's very unlikely that Nimsuggest EPC mode is responsible for this issue.