We benchmarked our VS Code fork against VS Code, Cursor, Antigravity and Zed

Hello everyone. We are the team behind Hyperlane, a fork of VS Code, and for the last few releases we have been quietly chipping away at startup time and memory. To see where we actually stand, we have been working on a benchmark that compares editors on equal terms and pointed it at our own editor, VS Code, Cursor and Antigravity (both also VS Code forks), and Zed (native, included for scale).

Before we get to any numbers, we want to be very clear that this is us benchmarking our own editor, on our own machine, with a benchmark we wrote ourselves. You have every reason to be sceptical of that setup, and honestly, so would we. That is why the benchmark is open source and why every number in this post comes out of a single report file you can also regenerate on your own hardware.

The short summary of this blog post is that according to our benchmark Hyperlane currently starts about 200 ms ahead of VS Code, about 1.1 seconds ahead of Antigravity and about 1.9 seconds ahead of Cursor, and holds somewhat less memory than all three, both idle and with a repository open, with the full results laid out below. The gap to VS Code in particular is very small by any measure, since VS Code is a well optimised editor and a couple hundred milliseconds is not a gap anybody feels in a day of work. We measured it as a check on our own work rather than as a race, because when we first measured we were behind VS Code as we had added many different new features on top of it. The Code-family editors here are the same editor underneath, running the same roughly 17 MB of workbench code on the same startup path, and what differs is only what each fork adds on top. We believe the difference comes from the optimisation work in these recent versions, where we moved our own code and features off the startup path and added caching and other ways of loading less and reusing more, and that work is what put Hyperlane ahead of the other VS Code forks in this batch.

Results

Everything below was measured on a Apple M5 Max with 128 GB of RAM on macOS 26.5.2, running Hyperlane v2026.08.7, Visual Studio Code 1.133.0, Cursor 3.9.16 and Antigravity 1.107.0. Absolute numbers are machine specific, so only the comparison inside the batch means much, and on slower hardware every number here is larger.

Startup is the time from process start to the editor reporting its workbench ready, using VS Code's own instrumentation, which every fork inherits unmodified. Each editor got ten measured runs after two warmup launches that were thrown away, and every single launch started from a fresh profile.

Standard deviations are between 4 and 7 ms for us, for VS Code and for Antigravity, while Cursor's launches spread over a wider range from run to run, and a Mann-Whitney U test against our runs puts every gap at p = 0.0002, so the ordering is resolvable at n = 10 and the fresh profile and the load gate are what keep the runs that tight. Even so, our gap to VS Code amounts to a fifth of a second that you pay exactly once, at launch.

With a real repository open

The benchmark also generates a deterministic TypeScript repository, 2,500 modules across 2,605 files, and launches each editor onto it with one file open, walking the whole process tree every 5 seconds for 3 minutes. Memory is summed RSS across the tree on macOS (the Linux path uses summed PSS, a different metric, so never compare numbers across the two). Steady is the median of the last minute, peak is the largest sample, and settle is the point after which nothing moved by more than 5% again.

We settle sooner and hold less memory once we get there, but the table also shows where we come off worse. We burn more CPU than VS Code in the first minutes because we index earlier and harder before going quiet, and once things settle we also sit a little higher than VS Code at idle, so there is real room left to improve here and we intend to.

What we changed

In our latest changes to achieve this result, most of it was actually looking back and trying to optimise as much of our code as possible, and the first half of the work was fixing our own mistakes. Very little of it is specific to an editor either, so if you are building an Electron app of your own the same list should help you too.

• Our interface, the services behind it, and some network work were all running eagerly while the workbench was still trying to become ready, which is the ordinary result of adding features to a fork and never going back to check when they run. VS Code already has lifecycle phases for exactly this, where a workbench contribution can be scheduled for the ready phase, the restored phase or eventually, and most of our code was registered for the earliest phase without ever needing to be. We profiled what actually runs before the workbench reports ready and moved everything that did not belong there to a later phase.
• The interface now builds itself the first time you open it instead of at launch. Our panels used to construct their DOM and wire up their listeners and services as part of window creation even when they started hidden, so every launch paid for surfaces nobody had opened yet. They now register only a lightweight description of themselves and the real view is constructed on first open.
• The network work now waits until the window is on screen. Requests like update checks and account state used to go out during startup, where they competed with the disk reads and the main thread work the first paint depends on, and nothing they return can be shown before the window exists anyway. They are now scheduled behind the restored phase and the launch no longer touches the network at all.

That cleanup alone got us level with upstream. The second half is where we felt a bit uneasy, since this is where we started going into more build related changes and Electron configuration, trying to cut as much as possible and adapt as much as we could to editor specific settings.

• One thing we added was V8 caching, where the engine can keep the compiled form of all that JavaScript and reuse it on the next launch instead of parsing and compiling everything again. We ship the cache with the app rather than making your first launch build one.
• Another thing we did is that we moved up to a more up to date Electron, which is unglamorous but the newer releases carry performance improvements we wanted to utilise.
• We also started deferring things in the editor. A surprising amount of what an editor loads at startup exists only so features can announce themselves, so we now load what the window needs and let the rest arrive once it is up.
• And we stopped animating unfocused windows nobody was looking at.

Although we made all of these cuts and optimisations, we were careful to keep the editor stable, and anything that made it less predictable we decided not to ship, for maintenance and user experience reasons. Thankfully there were not many cases where a change made the editor unstable.

The benchmark is open source

git clone https://github.com/Akkento/akkento-ide-bench
cd akkento-ide-bench

node bench.mjs --list                # which editors did it find, and where?
node bench.mjs --memory --workload   # benchmark all of them, memory and repo open

The whole benchmark is a single file with no dependencies and no network calls, and it writes a JSON report alongside a readable markdown one without sending anything anywhere.

Every launch gets a brand new throwaway profile, so run 10 is exactly as cold as run 1 and your real settings are never touched, and this matters because an editor carrying more profile state than its competitor loses over 100 ms to it, which is enough to decide a comparison on its own. The editors also take turns, so machine drift is shared instead of charged to whoever went last, and a load gate drops a run that never got a quiet machine rather than averaging it in, though every launch still lands in the report, warmups, timeouts and exclusions included.

The timing signal is upstream's rather than ours, since for everything built on Code it is --prof-append-timers, VS Code's own instrumentation, inherited unmodified by every fork, so no fork gets to define what counts as started.

Nothing about the benchmark is tied to our editor either, since it simply discovers whatever editors are installed on the machine and measures them all the same way, so you can point it at editors we have never mentioned here. We are hoping to grow it into a benchmark that people can actually rely on for this kind of comparison, and we intend to keep it updated as editors and their runtimes change.

Zed, for scale

We want to close the comparison with an editor we have a lot of respect for. We added Zed to the batch deliberately as it is so fast, and it is not a VS Code fork but a native editor written in Rust on its own GPU renderer, built by a team that cares about performance at a level we admire.

From the results we can see that Zed starts about 2.8 times faster than Hyperlane and holds less than an eighth of the memory with the repository open, which is a humbling pair of numbers to print in our own benchmark post. We are hoping to keep improving with every release so that our numbers move closer to Zed's, and even if a native editor will always have a head start over anything built on a browser engine, that distance is the yardstick we want to be measured against.

One note on fairness, and it is a point in Zed's favour rather than ours. Editors built on VS Code stop their own clock the moment they report themselves ready, while Zed is timed all the way from launch until its window is actually on screen, so Zed is being measured more strictly than everyone else in this post and its numbers are impressive.

If what you want is the smallest, quietest editor on your machine, that is unfortunately not us YET, and Zed is a wonderful choice that the benchmark will happily confirm on your own hardware. What we are working on is keeping the VS Code ecosystem while closing as much of that distance as an Electron app can, and having an editor like Zed around gives us something concrete to aim for.

What is next

We would like to be a lot closer to what a native editor like Zed feels like. Most of what we have shipped so far is careful use of what Electron and V8 already offer, and we think there is more of that left. Further out, forking Electron itself to strip it down to what an editor actually needs is something we would like to explore. We have not started that work, but it could be worth far more than the milliseconds in this post and hopefully cut the launch time and the memory usage further.

If you want to check any of this, run the benchmark on your own machine. Every number here comes out of a single report file, so if yours disagree with ours, please post them.

And if the numbers made you curious about the editor behind them, we would love for you to try Hyperlane. You keep the VS Code ecosystem you already know, you get a team that treats every millisecond and every megabyte as something worth fighting for, and every release from here on is aimed at making the numbers in this post look slow.