Ben Brandt
4ece4a635f
Builds on top of https://github.com/zed-industries/zed/pull/30942 This turns on incremental compilation and decreases extension compilation times by up to another 41% Putting us at roughly 92% improved extension load times from what is in the app today. Because we only have a static engine, I can't reset the cache between every run. So technically the benchmarks are always running with a warmed cache. So the first extension we load will take the 8.8ms, and then any subsequent extensions will be closer to the measured time in this benchmark. This is also measuring the entire load process, not just the compilation. However, since this is the loading we likely think of when thinking about extensions, I felt it was likely more helpful to see the impact on the overall time. This works because our extensions are largely the same Wasm bytecode (SDK code + std lib functions etc) with minor changes in the trait impl. The more different that extensions implementation is, there will be less benefit, however, there will always be a large part of every extension that is always the same across extensions, so this should be a speedup regardless. I used `moka` to provide a bound to the cache. We could use a bare `DashMap`, however if there was some issue this could lead to a memory leak. `moka` has some slight overhead, but makes sure that we don't go over 32mb while using an LRU-style mechanism for deciding which compilation artifacts to keep. I measured our current extensions to take roughly 512kb in the cache. Which means with a cap of 32mb, we can keep roughly 64 *completely novel* extensions with no overlap. Since our extensions will have more overlap than this though, we can actually keep much more in the cache without having to worry about it. #### Before: ``` load/1 time: [8.8301 ms 8.8616 ms 8.8931 ms] change: [-0.1880% +0.3221% +0.8679%] (p = 0.23 > 0.05) No change in performance detected. ``` #### After: ``` load/1 time: [5.1575 ms 5.1726 ms 5.1876 ms] change: [-41.894% -41.628% -41.350%] (p = 0.00 < 0.05) Performance has improved. ``` Release Notes: - N/A
Zed
Welcome to Zed, a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.
Installation
On macOS and Linux you can download Zed directly or install Zed via your local package manager.
Other platforms are not yet available:
- Windows (tracking issue)
- Web (tracking issue)
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.
Also... we're hiring! Check out our jobs page for open roles.
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.