From the creators of Zed

Delta brings meaningnathanmaxantonioback to your code

Your conversations and code live in one place. Delta anchors every change, so your reasoning lives on with the results.

DownloadD Open DeltaD Learn moreL

Pinned

Trace dropped keystrokes in GPUI inputs

Review element cache invalidation rules

Projects

zed

gpui

Cache SumTree node summaries

Investigate cache invalidationTrace summary propagation pathsCheck cursor invalidation callers

Fix IME candidate window positioning

Add scroll wheel phase events on macOS

Simplify Entity subscription cleanup

Reproduce stale text after window resize

cosmic-text

Threads

Summarize feedback on my first GPUI PR

Find a small rendering issue to work on

Explain retained mode rendering

Compare Metal frame capture tools

Draft release notes for accessibility fixes

[nathansobo]nathansoboZed

Cache SumTree node summaries

[nathansobo]

[maxbrunsfeld] as-cii

[as-cii]

[nathansobo]

Cursor::seek recomputes each internal node's summary on every descent for a rope of a few MB that's most of our seek time. Can we cache the summaries on the nodes and invalidate on edit?

Thought 3 times, ran 1 search, read 2 files

Edit crates/sum_tree/src/sum_tree.rs

    Internal {        height: u8,        summary: T::Summary,        summary_cache: SummaryCache<T::Summary>,        children: Vec<SumTree<T>>,

Edit crates/sum_tree/src/cursor.rs

            let mut end = self.position.clone();            end.add_summary(&child.compute_summary());            end.add_summary(child.cached_summary());            if end.cmp(target).is_ge() {

$ cargo test -p sum_tree 2>&1 | tail -20

Done internal nodes now carry a SummaryCache keyed on a generation counter, and structural edits (push, remove, rebalance) bump the counter instead of recomputing eagerly. Cursor::seek reads through the cache, so it only recomputes summaries for nodes whose subtree actually changed repeated seeks over an unedited region are pure cache hits. All 47 tests pass, including two new ones covering invalidation on push and on rebalancing.

[nathansobo]1 comment

repeated seeks over an unedited region are pure cache hits

[nathansobo]do we have a benchmark proving this?

[nathansobo]

[maxbrunsfeld]

repeated seeks over an unedited region are pure cache hits

[nathansobo]do we have a benchmark proving this?

let's back that claim with data before we merge add a criterion benchmark that seeks randomly through a tree of a million items, and share before/after numbers. i'd also like one seek-after-push case so we can see the invalidation cost on the spine.

$ cargo bench -p sum_tree -- seek

Benchmarked on a tree of one million items: random seeks went from 41.2s to 3.4s (12x), and seek-after-push lands at 5.1s the spine invalidation only forces one recompute per level. Criterion configs and the raw numbers are in benches/seek.rs.

[nathansobo] as-cii

[as-cii]

nice numbers. before we merge, extract SummaryCache into its own module and re-export it from lib.rs rope is going to want the same trick for chunk summaries.

Thought 1 time, ran 1 search

Edit crates/sum_tree/src/lib.rs

mod cursor;mod sum_tree;mod summary_cache;pub use cursor::Cursor;pub use summary_cache::SummaryCache;

Extracted SummaryCache lives in summary_cache.rs now and lib.rs re-exports it, so rope can depend on it without reaching into sum_tree's internals. No behavior change; the test suite is green.

[nathansobo]

[maxbrunsfeld]

what's the per-node memory overhead of the cache? we have trees with tens of millions of nodes in large buffers.

16 bytes per internal node on 64-bit targets: a usize generation plus Option<S> where the niche fits in the summary's padding for our summary types. Leaves carry nothing. For a 10M-node tree that's ~160MB in internal nodes but internal nodes are only ~1/32 of the total at our branching factor, so in practice it's closer to 5MB per 10M items.

[as-cii]1 comment

closer to 5MB per 10M items

[as-cii]Can we link the benchmark for this estimate?

[nathansobo]

delta/main

+64

HighFable 5

Changes

sum_tree.rs

cursor.rs

Sinceorigin/main+64

sum_tree.rscrates/sum_tree/src/

enum Node<T: Item> {22    Internal {23        height: u8,        summary: T::Summary,24        summary_cache: SummaryCache<T::Summary>,25        children: Vec<SumTree<T>>,26    },27    Leaf {28        items: Vec<T>,29    },}

    pub fn push(&mut self, item: T) {87        match Arc::make_mut(&mut self.0) {88            Node::Internal {                summary,89                summary_cache,90                children,91                ..92            } => {                *summary = compute_summary(children);93                summary_cache.invalidate();94                children95                    .last_mut()96                    .expect("internal nodes are never empty")97                    .push(item);

cursor.rscrates/sum_tree/src/

    fn descend(&mut self, subtree: &'a SumTree<T>, target: &T::Summary) -> bool {39        for (index, child) in subtree.children().iter().enumerate() {40            let mut end = self.position.clone();            end.add_summary(&child.compute_summary());41            end.add_summary(child.cached_summary());42            if end.cmp(target).is_ge() {

lib.rscrates/sum_tree/src/

1mod cursor;2mod sum_tree;3mod summary_cache;45pub use cursor::Cursor;6pub use sum_tree::{Item, SumTree, Summary};7pub use summary_cache::SummaryCache;

Coding with agents is multiplayer

Invite teammates into the same thread to review, comment, and work alongside the agent in real time.

Cache SumTree node summaries

[nathansobo]

[maxbrunsfeld] as-cii

[as-cii]

[nathansobo]

Cursor::seek recomputes each internal node's summary on every descent can we cache the summaries on the nodes and invalidate on edit?

Thought 3 times, ran 1 search, read 2 files

Done internal nodes now carry a SummaryCache keyed on a generation counter, and structural edits bump the counter instead of recomputing eagerly. Repeated seeks over an unedited region are pure cache hits.

[nathansobo]

[maxbrunsfeld]

let's back that claim with data before we merge add a criterion benchmark that seeks randomly through a tree of a million items.

Benchmarked on a tree of one million items: random seeks went from 41.2s to 3.4s (12x), and seek-after-push lands at 5.1s the spine invalidation only forces one recompute per level.

Share ThreadCopy Link

Invite by email, comma separatedInvite

[nathansobo]nathansoboOwner

General AccessOnly people invitedEveryone at ZedAnyone with the link

See how the code came to be

The thread stays connected to every change, so you understand the decisions and prompts behind the code.

Review in context

Comment on the conversation or any line of code. Your feedback stays anchored as the work evolves.

Done internal nodes now carry a SummaryCache keyed on a generation counter. Cursor::seek reads through the cache, so repeated seeks over an unedited region are pure cache hits.

[nathansobo]do we have a benchmark proving this?

Edit crates/sum_tree/src/sum_tree.rs

pub struct Node<S> {    children: ArrayVec<Node<S>, MAX>,    /// Cached aggregate, keyed on `generation`.    summary_cache: SummaryCache<S>,}

[maxbrunsfeld]mention that rebalancing also bumps the generation

Take your thread anywhere

Open Delta from the desktop or web, or move to a cloud runner. The conversation and code stay synchronized.

[nathansobo]

Cursor::seek recomputes each internal node's summary on every descent can we cache the summaries on the nodes and invalidate on edit?

Thought 3 times, ran 1 search, read 2 files

[nathansobo]

[maxbrunsfeld]

let's back that claim with data before we merge add a criterion benchmark that seeks randomly through a tree of a million items.

Benchmarked on a tree of one million items: random seeks went from 41.2s to 3.4s (12x), and seek-after-push lands at 5.1s the spine invalidation only forces one recompute per level.

LowClaude Fable 5

Local MachineCloud

1Delta, the app

Delta is a multiplayer environment for coding with agents. The unit of work is a thread: the conversation with an agent and the checkout of the repository it works in, kept together as one shareable artifact.

Learn More

2DeltaDB, the version control system

DeltaDB is the version control layer underneath Delta. Where Git captures a snapshot at each commit, DeltaDB records work as a stream of fine-grained deltas. Each delta has a stable identity, so a reference anchors to a change rather than a line number and survives as the code moves.

Learn More

Words from early adopters

Thousands of developers are already using Delta as their primary agentic development platform.

Delta is the most beautiful piece of software Ive used in a long time.

[]athas.dev@athasdev

Git remembers the commit. This remembers everything between them, including the conversation that wrote the code.

[]Digvijay Gujjarlapudi@digvijaysai_g

Code and conversations stay perfectly linked, and it genuinely elevates the whole process.

[]Jenil Desai@Jenxl_09

Why does Delta feel so good?

[]Ozzy@ozzy_build

The conversations, the decisions, the work, and the history all in one place. Context might be the killer feature of the agentic era.

[]Axel@itsmraxel

The team at Zed kinda cooked with Delta.

[]Sherlock@thesherlocker

I love having all the changes and context in threads.

[]Axel@itsmraxel

This is AI agent native Slack, Google Docs, and Wave that Ive been waiting for.

[]zmanian@zmanian

Reading code still matters, and I needed a proper interface to quickly jot down my comments and iterate quickly.

[]Jan-Peter Dhall@jempie_3

This is the most excited I have ever been about a product.

[]Andrew Atiya@atiya_ag

Delta is the most beautiful piece of software Ive used in a long time.

[]athas.dev@athasdev

Git remembers the commit. This remembers everything between them, including the conversation that wrote the code.

[]Digvijay Gujjarlapudi@digvijaysai_g

Code and conversations stay perfectly linked, and it genuinely elevates the whole process.

[]Jenil Desai@Jenxl_09

Why does Delta feel so good?

[]Ozzy@ozzy_build

The conversations, the decisions, the work, and the history all in one place. Context might be the killer feature of the agentic era.

[]Axel@itsmraxel

The team at Zed kinda cooked with Delta.

[]Sherlock@thesherlocker

I love having all the changes and context in threads.

[]Axel@itsmraxel

This is AI agent native Slack, Google Docs, and Wave that Ive been waiting for.

[]zmanian@zmanian

Reading code still matters, and I needed a proper interface to quickly jot down my comments and iterate quickly.

[]Jan-Peter Dhall@jempie_3

This is the most excited I have ever been about a product.

[]Andrew Atiya@atiya_ag

Download Delta NowD Open DeltaD

Terms PrivacyCookies