search

StefanSalewski / gintro

High level GObject-Introspection based GTK3/GTK4 bindings for Nim language
MIT License
298 stars 20 forks source link

Slow language server #116

Open gavr123456789 opened 3 years ago

gavr123456789 commented 3 years ago

I understand that this problem does not apply to gintro, but is there any way to solve it. It looks like LS compiles the project every time to provide functionality, without support for incremental compilation. Since gintro adds 56094 lines of binding code, this greatly worsens the LS response time even in the helloworldGTK project. Vala has a similar problem, but it manifests itself on much larger amounts of code(probably the compiler itself is just simpler).

GIF demo:
Peek 2021-03-16 17-29

Have other developers already encountered this problem, and how do they usually solve it?

StefanSalewski commented 3 years ago

That is an known problem, but reporting here is the wrong location. I am concerned with it even more as I also use the generic RTree and CDT modules. I use both with nimsuggest directly by my old pet editor. For strange syntax errors nimsuggest may sometimes even crash. Luckyly Nim is an easy languages, so I do not need nimsuggest that much. Syntax highlighting is done by pet without nimsuggest. I had a version which does highlighting with nimsuggest help, but that one generates high CPU load when one is editing.

So you may ask Araq directly, but be aware that he does not like GTK that much. We have more than 20 GUI libs for Nim now, I have listed them in my GTK4 book at the beginning. I assume that the tiny toy libs may work better with nimsuggest, as they are much smaller. Incremental compilation may help, but I don't know when it will become available. Other solutions could be to partition the gtk modules in tiny submodules, which you would have to import when needed. You may try yourself -- delete from gtk4.nim or the other related modules all what you may not need and see if performance improves.