Deryks _dev

Give it a stopwatch

The editor reports how long its own frame took.

Five edits. First, the standard library's clock:

editor/src/main.rstop of the file

use std::io;
use std::time::Instant;

Second and third — somewhere to keep the measurement, and a starting value:

editor/src/main.rsthe Editor struct

    status: String,
    frame_ms: f32,
}

editor/src/main.rsin Editor::open

            text,
            status,
            frame_ms: 0.0,
        }

Fourth — wrap the frame. Note that two of these lines go outside the panel closure, one at the very top of ui and one at the very bottom:

editor/src/main.rsin fn ui, around the panel

    fn ui(&mut self, ui: &mut egui::Ui, _frame: &mut eframe::Frame) {
        let frame_start = Instant::now();
        ui.ctx().request_repaint();

        egui::CentralPanel::default().show(ui, |ui| {
everything already inside the central panel, unchanged
        });

        self.frame_ms = frame_start.elapsed().as_secs_f32() * 1000.0;
    }

Fifth — show it, in the byte-count label you already have:

editor/src/main.rsin fn ui, the status label

            ui.label(format!("{position}  ·  {} bytes", self.text.len()));
            ui.label(format!(
                "{position}  ·  {} bytes  ·  {:.2} ms/frame",
                self.text.len(),
                self.frame_ms
            ));

Why it shows the previous frame

frame_ms is written after the panel has been drawn, so the label you just built is showing last frame's number. It can't show its own — the frame isn't over until after the label exists. Every frame-time readout in every program works this way.

request_repaint() is the other half. Rememberlesson 1: egui only repaints when something happens, so an idle editor would freeze the number at whatever it was when you last touched a key. Asking for a repaint every frame turns that off, which is exactly what you want while measuring and exactly what you'd remove afterwards — it burns CPU forever, which is the thing lesson 1 praised egui for avoiding.

cargo run
→ Ln 1, Col 1 · 31 bytes · 0.09 ms/frame
Small file, tiny number. That's the control.

Make the readout reachable

The status line stays put at the bottom of the window, whatever the file.

Before feeding it a huge file, try scrolling to the end of a merely large one. You can't — and the readout you just built lives below the text box, so on anything longer than the window it is pushed off-screen and unreachable. An instrument you can't read isn't an instrument.

Lesson 1 promised this fix: "later you'll add a top panel for tabs and a bottom one for a status bar, and the central panel will shrink to fit around them automatically." Four edits, and this is surgery — the file will not compile until all four are in. Do them all, then run.

First — the editor needs to remember the position between frames, because the status bar is now drawn before the text box that computes it:

editor/src/main.rsthe Editor struct

    status: String,
    position: String,
    frame_ms: f32,

Second — start it off with something sensible:

editor/src/main.rsin Editor::open

            status,
            position: "no cursor".to_owned(),
            frame_ms: 0.0,

Third — move both labels out of the central panel and into a bottom panel, declaredabove it:

editor/src/main.rsin fn ui, above the central panel

        ui.ctx().request_repaint();

        egui::Panel::bottom("status").show(ui, |ui| {
            ui.label(format!(
                "{}  ·  {} bytes  ·  {:.2} ms/frame",
                self.position,
                self.text.len(),
                self.frame_ms
            ));
            ui.label(&self.status);
        });

        egui::CentralPanel::default().show(ui, |ui| {

Fourth — delete the two old labels from the bottom of the central panel, wrap the text box in a scroll area, and store the position instead of printing it:

editor/src/main.rsin fn ui, the text box and the old labels

            egui::ScrollArea::vertical().show(ui, |ui| {
                let output = egui::TextEdit::multiline(&mut self.text)
                    .font(egui::TextStyle::Monospace)
                    .desired_width(f32::INFINITY)
                    .show(ui);

            let position = match output.cursor_range {
                self.position = match output.cursor_range {
the two match arms, unchanged — just indented one level further
                };
            ui.label(format!("{position}  ·  {} bytes", self.text.len()));
            });
        });

The status bar now shows the cursor position from the previousframe, because it's drawn first. That's the same one-frame lagframe_ms already had, for the same reason, and at 60 frames a second nobody has ever noticed.

cargo run
→ the status line sits at the bottom of the window and stays there
→ the text scrolls, and the readout doesn't move

Feed it something enormous

Watch the number move. No code — this stage is data collection.

Make a genuinely large source file — 50,000 lines, about 2 MB:

cd editor
seq 1 50000 | awk '{print " let value_" $1 " = compute(" $1 ") + 1;"}' > big.rs
wc -l big.rs
50000 big.rs — and it's disposable, delete it when you're done.

cargo run -- big.rs
→ scroll around, then type a character and watch the number

Two numbers matter, and they're very different. Idle is what you get while the text sits unchanged. Typing is what you get on the frames where the text changed. Here's what I measured on this machine:

A frame at 60 fps has 16.7 ms. So in the build you've been running all along, a 50,000-line file gives you about 14 frames per second while typing — the editor visibly lags behind your fingers.

Now run the same thing optimised:

cargo run --release -- big.rs
First build takes a minute — it's recompiling all 414 crates with optimisation.

This is also why performance complaints about Rust programs are worth one question before any other: release build? It's the same reason the toolchain reference tells you a debug-build editor feeling sluggish on a big file is not a bug.

Find out where the time actually goes

Time your own code separately, and stop guessing.

7 ms per keystroke in release is still 43% of a frame. Something is doing real work. The obvious suspect is line_col from lesson 4 — it walks the text from the start on every single frame, which is exactly the kind of thing that should scale badly. So measure it rather than assuming. Four edits.

editor/src/main.rsthe Editor struct

    frame_ms: f32,
    line_col_us: f32,
}

editor/src/main.rsin Editor::open

            frame_ms: 0.0,
            line_col_us: 0.0,
        }

editor/src/main.rsin fn ui, the Some arm inside the scroll area

                    Some(range) => {
                        let started = Instant::now();
                        let (line, column) = self.line_col(range.primary.index.0);
                        self.line_col_us = started.elapsed().as_secs_f32() * 1_000_000.0;
                        format!("Ln {line}, Col {column}")
                    }

Fourth — microseconds this time, not milliseconds — if you measure a small thing in big units you get 0.00 and learn nothing. Add it to the label:

editor/src/main.rsin fn ui, the label in the bottom panel

            ui.label(format!(
                "{}  ·  {} bytes  ·  {:.2} ms/frame",
                "{}  ·  {} bytes  ·  line_col {:.0} µs  ·  {:.2} ms/frame",
                self.position,
                self.text.len(),
                self.line_col_us,
                self.frame_ms
            ));

cargo run --release -- big.rs
→ press Ctrl+End to put the cursor at the very bottom, then type
→ … line_col 875 µs · 7.10 ms/frame

Read the two numbers together

line_col costs 0.875 ms of a 7.10 msframe. It is about an eighth of the cost. Real, worth fixing eventually — and nowhere near the thing that's making the editor slow.

So what is? Everything else in that frame, and almost all of it is one thing: egui lays out the entire 2 MB of text — every glyph position, every line wrap — every time the text changes. It doesn't know that you only changed one character near the top, and it doesn't know that you can only see forty lines of it.

This is the whole reason the lesson exists. The rope isn't wrong — it becomes right at a size and an edit pattern we haven't reached. But "obviously O(n), therefore obviously the bottleneck" is the most expensive kind of obvious.

O(n), said "order n", is shorthand for how an operation's cost grows with the size of its input — O(n) means double the text, double the work. String::insert is O(n) because everything after the cursor shifts along to make room.

The trap is that big-O describes the shape of that growth, not its height: it throws away the cost of each unit of work, which is the part that decides whether you notice. Look again at the table above — egui's text layout is O(n) in the file size too. Both suspects were linear, so the complexity class could not tell them apart at all — and the one that mattered cost some 560 times more per frame, because shaping a glyph and deciding where a line wraps is vastly more work than copying a byte. What big-O is good for is predicting what breaks later — it's a claim about scaling, not a measurement of what you have now.

rm editor/big.rs
cargo fmt && cargo clippy
Both silent. Keep the instrumentation — lesson 7 needs it.