as-cii
commented
6 years ago Hello @ZehCnaS34 and thanks for the feedback!
This being said, will the current architecture of XRay impede the performance of plugins like VimMode?
That's a good question. We haven't explored plugins architecture enough to provide a definite answer to it, but I feel pretty confident to say that it won't be the case. Even today, the UI and the model live in two different processes, but the overhead of communication is so low that e.g., even in the simple case of moving selections (or scrolling up/down), we are able to respond to the user action well before our frame budget ends.
Furthermore, from what I remember, the amount of computing time each plugin is allotted can also be throttled by VSCode’s core if need be.
I think this is a smart choice to prevent plugins from hindering the core experience or other packages' behavior. That said, however, assuming we end up doing something like that, I think we should still stick to the RAIL performance model and only throttle plugins when they violate one of those constraints.
I hope this answers your question. If it doesn't, please feel free to reopen this. 🙇
Hey,
I am a heavy user of the vim plugin on both Atom and VSCode. I’ve noticed that Atom’s vim package is a bit snappier than VSCode’s. I have a hunch that a large portion of the speed difference is caused by the plugin architecture of both editors. From what I understand, plugins in VSCode are running in Web Workers which rely on some form of message passing to communicate between the plugin and the editor’s core. Furthermore, from what I remember, the amount of computing time each plugin is allotted can also be throttled by VSCode’s core if need be. This being said, will the current architecture of XRay impede the performance of plugins like VimMode?
Finally, there are some discrepancies between functionality between the plugins pertaining to selection. I’m unsure if this is related to the architecture though.
The gif below shows the discrepancies between the way selections work.