top | item 39130782

(no title)

ra1231963 | 2 years ago

It doesn’t follow that a language server written with JavaScript and run via node will bloat the binary by hundreds of MB. Are they bundling a node runtime too?

Maybe if they are embedding dozens of language servers and runtimes it could bloat the binary, but I assumed the extensions and language servers would be downloaded on demand.

But a rust binary by itself shouldn’t be that large. LSP is just a simple json protocol, so parsing it doesn’t require hundreds of MB.

discuss

order

evmar|2 years ago

When I opened a Rust project I think the status bar said it was downloading Rust support, which supports your hypothesis. (Also it doesn't make much sense to bundle these things when they are all making new releases at different schedules.)

diodak|2 years ago

Hey, Zed developer here. Indeed we do not bundle the LSP binaries into the final binary for the reasons you've stated; and I do agree that the binary is kind of big, though at present .dmg compression gets us a long way (as the .dmg itself is ~115Mb). Right now we ship an universal binary, so half of that size is essentially unused:

  size /Applications/Zed.app/Contents/MacOS/zed
  __TEXT __DATA __OBJC others dec hex
  120979456 475136 0 4336828416 4458283008 109bc0000 zed (for 
  architecture x86_64)
  117587968 458752 0 4336680960 4454727680 10985c000 zed (for 
  architecture arm64)
Then, each of these binaries includes about 40MB of assets. I've actually had a PR up (https://github.com/zed-industries/zed/pull/3997) that reduced their size quite significantly, though that did not end up reducing the size of a .dmg itself, so I've scraped that. On top of that, we ship with debug symbols for symbolication of crashes (https://github.com/zed-industries/zed/blob/main/Cargo.toml#L...).