mirror of
https://github.com/zed-industries/zed.git
synced 2024-10-26 00:19:46 +00:00
Code at the speed of thought – Zed is a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.
080e25dd45
TL;DR: - shaves off about 0.5 seconds from most of our debug builds. - It would've slightly regressed release build due to preventing build pipelining, but as a tradeoff I've bumped up codegen-units for zed. \# What did you come up with this time Piotr In our zed repository I've noticed that merely *loading dependencies* in each crate takes non-trivial amount of time (~800ms in case of editor). That is to say, the moment you \`use editor\`, your build time increases by 800ms - this happens just once in crate though, as it looks like compiler has to load .rlibs of all of the referenced dependencies. This is visible under rustc's self-profile. Repro steps on twitter: https://twitter.com/PiotrOsiewicz/status/1762845413072101567 \# How does this commit alleviate this? zed lib + zed bin are on critical path of every build and cumulatively take about 3s to build. This commit bundles all of this up into ~2.2s of bin build time instead. \# Wait, splitting binary targets is good, no? Splitting up a binary target into lib + bin is generally considered to be a good practice, as you can then reuse the lib part elsewhere if needed. It also allows the build to kick off the moment metadata for all of the dependencies is available (thus, you don't need to wait for codegen). However, we do not really use zed as a lib, so the first benefit is not really a thing for us. The latter *is* indeed something we lose out on in release mode (in dev codegen phase of leaf-ish crates is insignificant, as we use shared generics - thus we don't spend much time codegening). That's why I've bumped codegen units for zed crate to 16 in release mode to keep build times in tact. |
||
|---|---|---|
| .cargo | ||
| .config | ||
| .github | ||
| .zed | ||
| assets | ||
| crates | ||
| docs | ||
| extensions | ||
| script | ||
| tooling/xtask | ||
| .dockerignore | ||
| .gitattributes | ||
| .gitignore | ||
| .gitmodules | ||
| .mailmap | ||
| Cargo.lock | ||
| Cargo.toml | ||
| CODE_OF_CONDUCT.md | ||
| CONTRIBUTING.md | ||
| debug.plist | ||
| docker-compose.sql | ||
| docker-compose.yml | ||
| Dockerfile | ||
| LICENSE-AGPL | ||
| LICENSE-APACHE | ||
| LICENSE-GPL | ||
| livekit.yaml | ||
| Procfile | ||
| README.md | ||
| rust-toolchain.toml | ||
| typos.toml | ||
Zed
Welcome to Zed, a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.
Installation
You can download Zed today for macOS (v10.15+).
Support for additional platforms is on our roadmap:
- Linux (tracking issue)
- Windows (tracking issue)
- Web (tracking issue)
For macOS users, you can also install Zed using Homebrew:
brew install zed
Alternatively, to install the Preview release:
brew tap homebrew/cask-versions
brew install zed-preview
Developing Zed
- Building Zed for macOS
- Building Zed for Linux
- Building Zed for Windows
- Running Collaboration Locally
Contributing
See CONTRIBUTING.md for ways you can contribute to Zed.
Licensing
License information for third party dependencies must be correctly provided for CI to pass.
We use cargo-about to automatically comply with open source licenses. If CI is failing, check the following:
- Is it showing a
no license specifiederror for a crate you've created? If so, addpublish = falseunder[package]in your crate's Cargo.toml. - Is the error
failed to satisfy license requirementsfor a dependency? If so, first determine what license the project has and whether this system is sufficient to comply with this license's requirements. If you're unsure, ask a lawyer. Once you've verified that this system is acceptable add the license's SPDX identifier to theacceptedarray inscript/licenses/zed-licenses.toml. - Is
cargo-aboutunable to find the license for a dependency? If so, add a clarification field at the end ofscript/licenses/zed-licenses.toml, as specified in the cargo-about book.