7 ms·

It's extremely refreshing to see the editor's memory and processor usage be smaller than the webapp tab I'm working on. I'm really liking it thus far!

eviks 11mo ago
Its binary is half a gig in size, so just like a browser, nothing fresh about that.
- zamadatix 11mo 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.
  - Rohansi 11mo ago
    What could they be statically linking to have a 400MB executable?
    - waterTanuki 11mo ago
      They wrote their own graphics renderering library for starters, that's bundled into the editor when compiled. https://www.gpui.rs/ https://www.gpui.rs/
      - typpilol 11mo ago
        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...
        trenchpilgrim 11mo ago
        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.
        bschwindHN 11mo ago
        You can read about it here: https://zed.dev/blog/videogame https://zed.dev/blog/videogame
      - Rohansi 11mo ago
        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.
      - 59nadir 11mo ago
        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.
    - 3836293648 11mo ago
      A tonne of treesitter grammars
  - adastra22 11mo ago
    The OS loads the entire binary into RAM.
    - nextaccountic 11mo ago
      It loads on demand, and pages you don't use don't need to be on RAM
- kstrauser 11mo ago
  It has a huge amount of treesitter modules, etc., statically compiled into the executable. They're not all loaded the instant you fire it up.
- waterTanuki 11mo ago
  considering how cheap storage is nowadays nitpicking about binary size is a very weird take. Are you editing code on an esp32?
  - archargelod 11mo ago
    I just refuse to use any software that baloons it's filesize. Not because I can't afford storage, but because there are always alternatives that have similar features and packed into fraction (usually less than 1%) of filesize. If one of them can do it and other can't, it's a bad product, that I have no intention to support. We should strive to write better software that is faster, smaller and more resilient. "Storage is cheap" is a bad mentality. This way of thinking is why software only gets worse with time: let's have a 400mb binary, let's use javascript for everything, who needs optimization - just buy top of the shelf super computer. And it's why terabytes of storage might not be enough soon.
    - waterTanuki 11mo ago
      I can empathize with how lazy some developers have gotten with program sizes. I stopped playing CoD because I refused to download their crap 150+ GB games with less content than alot of other titles that are much smaller. That said, storage is cheap, it's not a mentality but a simple statement of fact. You think zed balloons their file sizes because the developers are lazy. It's not true. It's because the users have become lazy. No one wants to spend time downloading the correct libraries to use software anymore. We've seen a rise in binary sizes in most software because of a rise in static linking, which does increase binary size, but makes using and testing the actual software much less of a pain. Not to mention the benefits in reduced memory overhead. VSCode and other editors aren't smaller because the developers are somehow better or more clever. They're using dynamic linking to call into libraries on the OS. This linking itself is a small overhead, but overhead none-the-less, and all so they can use electron + javascript, the real culprits which made people switch to neovim + zed in the first place. 400mb is such a cheap price to pay for a piece of software I use on a daily basis. I'm not here to convince you to use Zed or any editor for that matter. Use what you want. But you're not going to somehow change this trend by dying on this hill, because unless you're working with actual hardware constraints, dynamic linking makes no sense nowadays. There's no such thing as silver bullet in software. Everything is a tradeoff, and the resounding answer has been people are more than happy to trade disk space for lower memory & cpu usage.
lexoj 11mo ago
Just be sure about that because zed fires up node as well for lsp.

eviks 11mo ago

Its binary is half a gig in size, so just like a browser, nothing fresh about that.

zamadatix 11mo 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.
- Rohansi 11mo ago
  What could they be statically linking to have a 400MB executable?
  - waterTanuki 11mo ago
    They wrote their own graphics renderering library for starters, that's bundled into the editor when compiled. https://www.gpui.rs/ https://www.gpui.rs/
    - typpilol 11mo ago
      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...
      - trenchpilgrim 11mo ago
        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.
      - bschwindHN 11mo ago
        You can read about it here: https://zed.dev/blog/videogame https://zed.dev/blog/videogame
    - Rohansi 11mo ago
      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.
    - 59nadir 11mo ago
      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.
  - 3836293648 11mo ago
    A tonne of treesitter grammars
- adastra22 11mo ago
  The OS loads the entire binary into RAM.
  - nextaccountic 11mo ago
    It loads on demand, and pages you don't use don't need to be on RAM
kstrauser 11mo ago
It has a huge amount of treesitter modules, etc., statically compiled into the executable. They're not all loaded the instant you fire it up.
waterTanuki 11mo ago
considering how cheap storage is nowadays nitpicking about binary size is a very weird take. Are you editing code on an esp32?
- archargelod 11mo ago
  I just refuse to use any software that baloons it's filesize. Not because I can't afford storage, but because there are always alternatives that have similar features and packed into fraction (usually less than 1%) of filesize. If one of them can do it and other can't, it's a bad product, that I have no intention to support. We should strive to write better software that is faster, smaller and more resilient. "Storage is cheap" is a bad mentality. This way of thinking is why software only gets worse with time: let's have a 400mb binary, let's use javascript for everything, who needs optimization - just buy top of the shelf super computer. And it's why terabytes of storage might not be enough soon.
  - waterTanuki 11mo ago
    I can empathize with how lazy some developers have gotten with program sizes. I stopped playing CoD because I refused to download their crap 150+ GB games with less content than alot of other titles that are much smaller. That said, storage is cheap, it's not a mentality but a simple statement of fact. You think zed balloons their file sizes because the developers are lazy. It's not true. It's because the users have become lazy. No one wants to spend time downloading the correct libraries to use software anymore. We've seen a rise in binary sizes in most software because of a rise in static linking, which does increase binary size, but makes using and testing the actual software much less of a pain. Not to mention the benefits in reduced memory overhead. VSCode and other editors aren't smaller because the developers are somehow better or more clever. They're using dynamic linking to call into libraries on the OS. This linking itself is a small overhead, but overhead none-the-less, and all so they can use electron + javascript, the real culprits which made people switch to neovim + zed in the first place. 400mb is such a cheap price to pay for a piece of software I use on a daily basis. I'm not here to convince you to use Zed or any editor for that matter. Use what you want. But you're not going to somehow change this trend by dying on this hill, because unless you're working with actual hardware constraints, dynamic linking makes no sense nowadays. There's no such thing as silver bullet in software. Everything is a tradeoff, and the resounding answer has been people are more than happy to trade disk space for lower memory & cpu usage.

lexoj 11mo ago

Just be sure about that because zed fires up node as well for lsp.