Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve: Performance tuning #388

Closed
HerringtonDarkholme opened this issue Aug 16, 2017 · 2 comments
Closed

Improve: Performance tuning #388

HerringtonDarkholme opened this issue Aug 16, 2017 · 2 comments

Comments

@HerringtonDarkholme
Copy link
Member

HerringtonDarkholme commented Aug 16, 2017

This issue would be a meta issue, logging all the field we can improve performance.

Async

Currently we return result in sync fashion. However, vscode-langauge-server accepts Promise based return value.

Sync value has several drawbacks:

  1. One single slow command blocks the whole server
  2. Hard to exploit multiple CPUs
  3. No way to use dynamic import, this blocks lazy loading

We can change our underlying service interface to support it.

Component Resolution

We now uses a single findComponents function to resolve all component info. This might make our completion laggy. #436 . But TagProvider, the consumer of findComponents, does require one single component at a time.

We can improve findComponents and related functions to do less work in completion.

Block Doc Version & Incremental Change.

Vetur split different SFC block into different TextDocument. They are share the same version. Thus, updating in template block will force vetur to unnecessarily reparse script block.

@HerringtonDarkholme HerringtonDarkholme self-assigned this Aug 16, 2017
@HerringtonDarkholme HerringtonDarkholme changed the title Suggestion: Use async fashion in vscode-language-server Improve: Performance tuning Sep 21, 2017
@octref
Copy link
Member

octref commented Nov 1, 2017

Not using async actually blocks some features. I'll do the migration soon.

@octref octref added the perf label Aug 10, 2018
@octref octref added this to the March 2019 milestone Mar 18, 2019
@octref
Copy link
Member

octref commented Mar 18, 2019

This would block #682 so doing it now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants