Hacker News new | ask | show | jobs
by zamadatix 246 days ago
Size on disk is about 64x less relevant than size in RAM for me. To give Zed some credit in this area, it's statically linked and the Linux binary is half the size as the Windows one.
2 comments

What could they be statically linking to have a 400MB executable?
A tonne of treesitter grammars
They wrote their own graphics renderering library for starters, that's bundled into the editor when compiled.

https://www.gpui.rs/

Every Unity game ships with three UI frameworks (IMGUI, UGUI, UI Elements) built-in, in addition to everything else the game engine supports, and the engine is only about 50 MB.
Is that really necessary for an ide? Seems like a ton of added complexity for little to no trade off or even a downside considering...
Yes. Zed is snappy in a way that makes my copy of Sublime Text 3 feel slow. Compared to VSC it feels like going from a video game at 40 FPS with 2-3 frames of input lag to 120 FPS.
You can read about it here:

https://zed.dev/blog/videogame

A renderer/rendering library for something as simple as a text editor is not (or is not supposed to be) a lot of code and should not take up a large amount of space in a binary. Odds are good it's the embedded Treesitter grammars and other things that Zed uses that takes up space.

It is Rust software, so there is probably a good 50-90% waste when it comes to just raw needed vs. actual lines of code in there, but there is no way anyone makes a renderer so overcomplicated that it takes up a meaningful part of the 500 MB or so Zed takes up on Windows.

The OS loads the entire binary into RAM.
It loads on demand, and pages you don't use don't need to be on RAM