investigate bun

[DetachHead]

it might make pyright faster

[znd4]

Barely on-topic, but would it be easy to allow "bring your own pyright / node / bun"? If so, it'd probably be pretty easy to implement a solution for #177, although it'd require a bit of maintenance to keep the pyright version correct.

I'll try digging into the code to see if there's a light-touch way to implement this.

[KotlinIsland]

It wouldn't be possible to bring your own pyright, this project is setup such that it modifies a lot of source, not just acts as an 'expansion pack'.

[DetachHead]

i might add an option to byo node, which would hopefully fix these issues: #177 #172 #167

when i first started this project, i just wanted it to be a vscode extension where users could specify any version of pyright (the only issue i was trying to fix at the time was the ability to pin the version used by vscode), but i literally couldn't get the language server to work without modifying how the pyright language server is built (c1c8be9) so i gave up on that approach. i think even if we can get it working, it's not something worth supporting. basedpyright's additional functionality can be disabled to have essentially a backwards-compatible version of pyright, which i think covers that use case.

[jfcherng]

Just want to share my test on a Win11 x64 PC with the recent Bun v1.1.0, which is the first release supporting Windows.

I don't "feel" (no numerical statistics, just my feeling) it's obviously faster, but it consumes much more memory than electron/node. I use bun/electron/node to run Pylance on the same Python project.

---

Just an FYI, you can use Electron to run as node by setting env variable ELECTRON_RUN_AS_NODE=1 and it consume less memory (and CPU?) due to its optimizations. This is what I do for all node.js-based LSP servers on my local setup in Sublime Text.

[DetachHead]

yeah don't think there's any benefit to doing this atm. can re-open this issue in the future if that changes. see #202 (comment)