search

lostintangent / codeswing

VS Code extension for building web applications ("swings") using a interactive and editor-integrated coding environment
https://aka.ms/codeswing
MIT License
977 stars 45 forks source link

Optimize extension activation #22

Closed jasonwilliams closed 3 years ago

jasonwilliams commented 3 years ago

Hey this extension looks great!

For activationEvents try to avoid using *. Using * means this extension will startup and activate even if someone is not using it. It will also incur a (albeit small) startup cost for users.

As this extension seems to be command driven you can put the commands in there instead, that way it won't slow down performance when not in use. More info here: https://code.visualstudio.com/api/references/activation-events#Start-up

If you open a directory in VS Code, and that directory represents a swing, then the swing environment will be automatically launched.

I'm not sure how you detect this but you can have the extension activate if a certain file is in the workspace (there's an example of that here) or if there's really other option onStartupFinished may be better

lostintangent commented 3 years ago

The reason I went with * is because the logic for detecting a "swing" workspace is dynamic (e.g. other extensions can extend CodeSwing), and therefore, a static list of workspaceContains conditions wouldn't be entirely sufficient.

Additionally, CodeSwing exports an API for other extensions to use (e.g. GistPad), and since there's no activation event for other extensions trying to use your API, these consumers would need to manually check if CodeSwing was activated, and if not, activate it. That's definitely not difficult to do, but I wanted to keep things simple since this extension is super new, and I'm exploring integrations with various folks.

Since the onStartupFinished event doesn't guarantee when it will be triggered, I was also a little hesitant to relying on it, since it could introduce seconds of latency when trying to open a swing workspace (depending on the extensions/etc. the user has). Once again, not the end of the world. But using * provides a couple of nice properties, that couldn't be fully emulated with other activation events.

Out of curiosity: are you seeing CodeSwing impact your startup time? Or did you just see the activation event in the extension details page? I'll do some profiling to see how to further streamline startup, since it should be pretty negligible. And I'll play around with onStartupFinished to see how it "feels" across different usage scenarios.

jasonwilliams commented 3 years ago

Hey @lostintangent thats fair enough and thanks for your reply!

I haven’t noticed any impact but I thought it was worth pointing out as when a few extensions do this it can start to build up.

Some other extensions switched to onStartupFinished and didn’t notice any impact but I’ll leave that for you to experiment.

lostintangent commented 3 years ago

Yep totally agreed. I may be able to achieve a startup experience that's optimized for the majority of scenarios, and then relies on onStartupFinished as a "fallback".

lostintangent commented 3 years ago

Just pushed an extension update that activates using onStartupFinished, when a command is run, or when a workspace is opened that contains a codeswing.json file at the root. Thanks for the feedback and let me know if you have any other feedback!

jasonwilliams commented 3 years ago

That’s awesome! Thanks @lostintangent