Closed Josverl closed 2 years ago
@jakobrosenberg please take a look
Hi @Josverl, are you using v1.1.13 or v1.1.14-beta.0?
Hi Jacob, initial report was on v1.1.13 , Just did quick test of the v.1.14-beta, and
that feels snappier - and the timings also look much better :
## Extension Activation Stats
| Extension | Eager | Load Code | Call Activate | Finish Activate | Event | By |
| --------------------------------------- | ----- | --------- | ------------- | --------------- | ------------------------------------ | --------------------------------------- |
| vscode.debug-auto-launch | true | 7 | 0 | 179 | * | vscode.debug-auto-launch |
| GitHub.codespaces | true | 253 | 22 | 3760 | * | GitHub.codespaces |
| madewithcardsio.adaptivecardsstudiobeta | true | 705 | 2 | 154 | * | madewithcardsio.adaptivecardsstudiobeta |
| mhutchie.git-graph | true | 75 | 5 | 683 | * | mhutchie.git-graph |
| ms-python.python | true | 58 | 5 | 799 | workspaceContains:pyproject.toml | ms-python.python |
| ms-python.vscode-pylance | true | 207 | 1 | 161 | workspaceContains:pyrightconfig.json | ms-python.vscode-pylance |
| pycom.pymakr | true | 106 | 128 | 20 | * | pycom.pymakr |
| ritwickdey.LiveServer | true | 995 | 8 | 12 | * | ritwickdey.LiveServer |
That is a factor 166 faster 🏎️🏎️ for the 2 samples provided, Kudos !. If this are the result, just keep removing the code that I monkey-patched in the loader to get things working :-)
Also notice that the other eager
extensions finish activation much quicker as well , so there is obviously some interaction there
I have my hopes that bundling can push that down even further (below the 20 ms )
@Josverl is this still an issue with v.1.1.15
? Bindings are only downloaded if no working bindings are found, so the higher load time should only happen whenever VSCode upgrades Electron.
Hi Jacob,
v1.14 and v1.15 are now much quicker under normal load. A one time pre upgrade delay is no problem, a very small price to pay for the automagic🪄 download of new bindings.
## Extension Activation Stats
| Extension | Eager | Load Code | Call Activate | Finish Activate | Event | By |
| ------------------------------------- | ----- | --------- | ------------- | --------------- | --------------------------------- | ------------------------------------- |
| vscode.debug-auto-launch | true | 15 | 0 | 172 | * | vscode.debug-auto-launch |
| vscode.git | true | 45 | 16 | 560 | * | vscode.github |
| johnpapa.vscode-peacock | true | 10 | 1 | 6006 | * | johnpapa.vscode-peacock |
| mhutchie.git-graph | true | 114 | 7 | 580 | * | mhutchie.git-graph |
| pycom.pymakr | true | 479 | 92 | 232 | * | pycom.pymakr |
| streetsidesoftware.code-spell-checker | true | 58 | 0 | 288 | * | streetsidesoftware.code-spell-checker |
I think it can be be even faster, as is also indicated by the warning during the build process:
This extension consists of 8326 files, out of which 5130 are JavaScript files. For performance reasons, you should bundle your extension
https://aka.ms/vscode-bundle-extension
Previously I have tried bundling though webpack, and failed in spectacular ways, perhaps ESBuild is better suited.
I'll close this issue and create a new issue to track the bundling opportunity.
Feature Request 🚀
Is your feature request related to a problem? Please describe.
Pymakr is slow to start : a sample trace :
Note: the 21295 ms really stands out
> Developer: Startup Performance
orcode --performance
Describe the solution you'd like
Startup duration to take significantly less time.
Describe alternatives you've considered
Currently I (need to) disable pymakr globally to prevent non-MicroPython projects from being slowed down
- https://code.visualstudio.com/api/working-with-extensions/bundling-extension
Teachability, Documentation, Adoption, Migration Strategy
Version info:
Pymakr: Version: 1.1.13
VSCode: Version: 1.60.2 (user setup) Commit: 7f6ab5485bbc008386c4386d08766667e155244e Date: 2021-09-22T12:00:31.514Z Electron: 13.1.8 Chrome: 91.0.4472.164 Node.js: 14.16.0 V8: 9.1.269.39-electron.0 OS: Windows_NT x64 10.0.22000