4 ms·

Strangely it's the actual binary's .text section that's about 400MB. Time to dive in!

pjmlp 1y ago
Welcome to static linking of large applications. The world moved into dynamic linking in the 1980's for a reason. It is cool to advocate for a return to static linking when it is basic CLI tools.
- trenchpilgrim 1y ago
  > The world moved into dynamic linking in the 1980's for a reason. Reasons that no longer exist. Storage is cheap, update distribution is free, time spent debugging various shared lib versions across OSes is expensive.
  - pjmlp 1y ago
    Yet everyone is complaining on this thread about Zed distribution size, go figure. They should shut up and just buy bigger drives. Ah, they can't on their laptops, bummer. Also try to develop mobile apps with that mentality, https://www.abbacustechnologies.com/why-your-app-keeps-getting-uninstalled-mobile-app-development-solutions/ https://www.abbacustechnologies.com/why-your-app-keeps-getti...
    - tremarley 1y ago
      Precisely. It seems like the people who say storage is cheap assume everyone is using desktop PCs
      - edgineer 1y ago
        Storage is cheap and upgradeable on all but very very few Windows laptops.
    - ChrisSD 1y ago
      Tbh, the rights and wrongs aside, I suspect "everyone" is complaining about it because it's the easiest thing to talk about. Much like how feature discussions tend towards bikeshedding.
  - mort96 1y ago
    Storage doesn't really feel cheap. I'm considering buying a new laptop, and Apple charges $600 per TB. Sure, it's cheaper than it was in the '80s, but wasting a few gigabytes here and a few gigabytes there is quickly enough to at least force you to go from a 500GB drive to a 1TB drive, which costs $300.
    - trenchpilgrim 1y ago
      That's more of an Apple problem? Storage is under $50/TB.
      - mort96 1y ago
        It's the reality of storage pricing. The general statement "storage is cheap" is incorrect. For some practically relevant purposes, such as Apple laptops, it's $600/TB. For other purposes, it's significantly below $50/TB. You could say "just don't buy Apple products". And sure, that might be a solution for some. But the question of what laptop to buy is an extremely complicated one, where storage pricing is just one of many, many, many different factors. I personally have landed on Apple laptops, for a whole host of reasons which have nothing to do with storage. That means that if I have to bump my storage from 1TB to 2TB, it directly costs me $600.
    - juliangmp 1y ago
      If you're buying Apple then you should expect inflated prices. I got a 4TB NVMe SSD for like 350€, a 2TB one goes from 122 - 220 € depending on read/write speeds. I don't check the installation size of applications anymore.
      - mort96 1y ago
        I'm just saying that $600/TB is a real storage price that lots of people deal with. Storage isn't universally cheap. This feels especially relevant since we're discussing Zed here, the Mac-focused developer tool, and developers working on Mac are the exact people who pay $600/TB.
    - Fokamul 1y ago
  - HeckFeck 1y ago
    Big sigh. I wish we still had pride in our field, rather than this race to the bottom mentality.
  - homebrewer 1y ago
    RAM isn't cheap (it may be for your tasks and wallet depth, but generally it isn't, especially since DDR5). Shared objects also get "deduplicated" in RAM, not just on disk.
    - trenchpilgrim 1y ago
      What objects is the Zed process using that would even be shared with any other process on my system? Language support is mostly via external language servers. It uses its own graphics framework, so the UI code wouldn't be shared. A huge amount of the executable size is tree-sitter related.
      - deleted 1y ago
        [deleted]
  - juliangmp 1y ago
    I 100% agree. As soon as you step outside of the comfort of your Linux distributions' package manager, dynamic linking turns into dependency hell. And the magic solution to that problem our industry has come up with is packaging half an OS inside of a container...
  - vthriller 1y ago
    > Storage is cheap My /usr is 15G already, and /var/lib/docker isn't that far off despite people's obsession with alpine images. If more people would dismiss storage as cheap it'll quickly become expensive, just not per GiB. > update distribution is free I wouldn't be surprised if at one point Github would start restricting asset downloads for very popular projects simply because of how much traffic they'd generate. Also, there's still plenty of places on the planet with relatively slow internet connectivity.
  - nottorp 1y ago
    > Storage is cheap I'll be very grateful if you stopped using all my RAM for two buttons and a scrollbar thank you.
    - trenchpilgrim 1y ago
      OSes don't load the full executable into physical RAM, only the pages in the working set. Most of the Zed executable's size is tree-sitter code for all the supported languages, and only needs to page in if those languages are being used in a project.
      - nottorp 1y ago
        Maybe for this particular case but the comment shows a certain mindset...
- landr0id 1y ago
  I say "strangely" because honestly it just seems large for any application. I thought they might not be doing LTO or something but they do thin LTO. It's just really that much code.
- magackame 1y ago
  All those beautiful dlls will anyways sit comfortably in the same folder as your "dynamically" linked executable on Windows.
  - pjmlp 1y ago
    They might be, or not.
- bowsamic 1y ago
  I really like this article "How Swift Achieved Dynamic Linking Where Rust Couldn't" https://faultlore.com/blah/swift-abi https://faultlore.com/blah/swift-abi
- torginus 1y ago
  I think there should be a best-of-both-worlds type of linking - during compilation, the linker places a statically compiled library at a certain address, but doesn't include it in the binary. Then, during startup, the OS maps the same library to the given address (sharing the data between processes). This would improve memory use and startup time both and performance, avoiding dynamic linking. Of course you need to match the exact versions between the compiled executable and the dependency, but this should be a best practice anyways.
  - trenchpilgrim 1y ago
    Static linkers generally don't compile a "full copy" of the library. Just the code paths the compiled application uses. The compiler may have also made optimizations based on the apppication's usage patterns.
vilhelm_s 1y ago
The Rust compiler always produces quite large binaries compared to other programming language. I notice there's a (closed) issue on the Zed github [https://github.com/zed-industries/zed/issues/34376 https://github.com/zed-industries/zed/issues/34376], > At this time, we prioritize performance and out-of-the-box functionality over minimal binary size. As is, this issue isn't very actionable, but if you have concrete optimization ideas that don't compromise these priorities, we'd be happy to consider them in a new issue.

Welcome to static linking of large applications. The world moved into dynamic linking in the 1980's for a reason. It is cool to advocate for a return to static linking when it is basic CLI tools.

trenchpilgrim 1y ago
> The world moved into dynamic linking in the 1980's for a reason. Reasons that no longer exist. Storage is cheap, update distribution is free, time spent debugging various shared lib versions across OSes is expensive.
- pjmlp 1y ago
  Yet everyone is complaining on this thread about Zed distribution size, go figure. They should shut up and just buy bigger drives. Ah, they can't on their laptops, bummer. Also try to develop mobile apps with that mentality, https://www.abbacustechnologies.com/why-your-app-keeps-getting-uninstalled-mobile-app-development-solutions/ https://www.abbacustechnologies.com/why-your-app-keeps-getti...
  - tremarley 1y ago
    Precisely. It seems like the people who say storage is cheap assume everyone is using desktop PCs
    - edgineer 1y ago
      Storage is cheap and upgradeable on all but very very few Windows laptops.
  - ChrisSD 1y ago
    Tbh, the rights and wrongs aside, I suspect "everyone" is complaining about it because it's the easiest thing to talk about. Much like how feature discussions tend towards bikeshedding.
- mort96 1y ago
  Storage doesn't really feel cheap. I'm considering buying a new laptop, and Apple charges $600 per TB. Sure, it's cheaper than it was in the '80s, but wasting a few gigabytes here and a few gigabytes there is quickly enough to at least force you to go from a 500GB drive to a 1TB drive, which costs $300.
  - trenchpilgrim 1y ago
    That's more of an Apple problem? Storage is under $50/TB.
    - mort96 1y ago
      It's the reality of storage pricing. The general statement "storage is cheap" is incorrect. For some practically relevant purposes, such as Apple laptops, it's $600/TB. For other purposes, it's significantly below $50/TB. You could say "just don't buy Apple products". And sure, that might be a solution for some. But the question of what laptop to buy is an extremely complicated one, where storage pricing is just one of many, many, many different factors. I personally have landed on Apple laptops, for a whole host of reasons which have nothing to do with storage. That means that if I have to bump my storage from 1TB to 2TB, it directly costs me $600.
  - juliangmp 1y ago
    If you're buying Apple then you should expect inflated prices. I got a 4TB NVMe SSD for like 350€, a 2TB one goes from 122 - 220 € depending on read/write speeds. I don't check the installation size of applications anymore.
    - mort96 1y ago
      I'm just saying that $600/TB is a real storage price that lots of people deal with. Storage isn't universally cheap. This feels especially relevant since we're discussing Zed here, the Mac-focused developer tool, and developers working on Mac are the exact people who pay $600/TB.
  - Fokamul 1y ago
- HeckFeck 1y ago
  Big sigh. I wish we still had pride in our field, rather than this race to the bottom mentality.
- homebrewer 1y ago
  RAM isn't cheap (it may be for your tasks and wallet depth, but generally it isn't, especially since DDR5). Shared objects also get "deduplicated" in RAM, not just on disk.
  - trenchpilgrim 1y ago
    What objects is the Zed process using that would even be shared with any other process on my system? Language support is mostly via external language servers. It uses its own graphics framework, so the UI code wouldn't be shared. A huge amount of the executable size is tree-sitter related.
    - deleted 1y ago
      [deleted]
- juliangmp 1y ago
  I 100% agree. As soon as you step outside of the comfort of your Linux distributions' package manager, dynamic linking turns into dependency hell. And the magic solution to that problem our industry has come up with is packaging half an OS inside of a container...
- vthriller 1y ago
  > Storage is cheap My /usr is 15G already, and /var/lib/docker isn't that far off despite people's obsession with alpine images. If more people would dismiss storage as cheap it'll quickly become expensive, just not per GiB. > update distribution is free I wouldn't be surprised if at one point Github would start restricting asset downloads for very popular projects simply because of how much traffic they'd generate. Also, there's still plenty of places on the planet with relatively slow internet connectivity.
- nottorp 1y ago
  > Storage is cheap I'll be very grateful if you stopped using all my RAM for two buttons and a scrollbar thank you.
  - trenchpilgrim 1y ago
    OSes don't load the full executable into physical RAM, only the pages in the working set. Most of the Zed executable's size is tree-sitter code for all the supported languages, and only needs to page in if those languages are being used in a project.
    - nottorp 1y ago
      Maybe for this particular case but the comment shows a certain mindset...
landr0id 1y ago
I say "strangely" because honestly it just seems large for any application. I thought they might not be doing LTO or something but they do thin LTO. It's just really that much code.
magackame 1y ago
All those beautiful dlls will anyways sit comfortably in the same folder as your "dynamically" linked executable on Windows.
- pjmlp 1y ago
  They might be, or not.
bowsamic 1y ago
I really like this article "How Swift Achieved Dynamic Linking Where Rust Couldn't" https://faultlore.com/blah/swift-abi https://faultlore.com/blah/swift-abi
torginus 1y ago
I think there should be a best-of-both-worlds type of linking - during compilation, the linker places a statically compiled library at a certain address, but doesn't include it in the binary. Then, during startup, the OS maps the same library to the given address (sharing the data between processes). This would improve memory use and startup time both and performance, avoiding dynamic linking. Of course you need to match the exact versions between the compiled executable and the dependency, but this should be a best practice anyways.
- trenchpilgrim 1y ago
  Static linkers generally don't compile a "full copy" of the library. Just the code paths the compiled application uses. The compiler may have also made optimizations based on the apppication's usage patterns.

vilhelm_s 1y ago

The Rust compiler always produces quite large binaries compared to other programming language. I notice there's a (closed) issue on the Zed github [https://github.com/zed-industries/zed/issues/34376 https://github.com/zed-industries/zed/issues/34376], > At this time, we prioritize performance and out-of-the-box functionality over minimal binary size. As is, this issue isn't very actionable, but if you have concrete optimization ideas that don't compromise these priorities, we'd be happy to consider them in a new issue.