Recompiling the project renders the extension unusable for extended periods

[0xEVom]

Every time a file is modified, Wake recompiles the entire project and runs all detectors again, which can take 10s of seconds for larger projects. During this time, language support in the IDE is severely limited and basic functionality such as code references is unavailable.

This is exacerbated by the fact that the entire project is recompiled and analyzed regardless of the extent of the changes, whether only one file was modified or there was no actual change to the bytecode.

I have auto-save enabled in my IDE, which makes this a persistent issue and I would say my biggest pain point in using the extension. The only setting I've found that helps a bit with this is wake.lsp.compilation_delay, which at least allows me to prevent triggering recompilation as long as I'm typing, but it only minimally alleviates the situation.

I would love to see all of this happen behind the scenes and changes to the symbol index and diagnostics only take effect once they're ready. Ideally, the extension should use the current state to markedly cut down on time to readiness on recompilation.

[michprev]

@0xEVom thank you for your feedback.

There's an optimization already implemented that might help in the cases you're describing, but based on your experience (and even our experience) it's just not enough.

Let me explain on the Go to definition feature. Wake stores the latest compilation artifacts and when a Go to definition query occurs when there's ongoing compilation, the latest (finalized) artifacts may be used. A text diff (similar to git diff) is generated for the relevant files (i.e. the "source" file where the user clicks and the "destination" file where the definition exists). If there are no text changes to the code where the user clicked and to the definition, it's possible to compute the text location delta and serve the correct response.

However, there are certain limitations:

• a text diff may give us misleading info about the changed file segments, especially when a significant part of a file was modified since the last compilation,
  • a semantic diff (a diff between two parser outputs - trees) can be used to better mitigate the problem (not implemented yet),
• Python does not allow two CPU-bound tasks to run at the same time (there's GIL to prevent race conditions while interpreting Python code),
  • this is not the case of running solc instances as these run in separate processes,
  • post-compilation analysis (after solc run finishes) however is CPU-bound, as well as serving LSP responses and running vulnerability & code quality detectors,
  • it would be inefficient to create a new process for post-compilation analysis (incl. detectors),
  • however, it's possible to switch the execution context let's say between each detector run to give the LSP server time to respond to at least some LSP requests (not implemented).

So there is a possibility to better mitigate the problem, but the implementation is non-trivial, it's not guaranteed that new changes would help and so it's not on the top of the priority list right now.