Deryks _dev

Point the instrument at your own feature

Numbers, from your editor, on files of five different sizes.

No code this stage. Build the files and read the frame counter you already have:

cd editor
for n in 1000 5000 10000 25000 50000; do
  seq 1 $n | awk '{print " let value_" $1 " = compute(" $1 "); // note"}' > big-$n.rs
done
Five files, 40 KB to 2.2 MB. All disposable.

cargo run --release -- big-50000.rs
→ scroll, type a character, read the ms/frame
Release. Lesson 6's most useful number was that debug lies to you by 10×.

Here's what I measured, with lesson 7's highlighting on and — for comparison — the plain single-colour layouter from lesson 7 stage 1:

Highlighting costs roughly 4–5× the plain layout, and it crosses the 16.7 ms frame budget somewhere between 10,000 and 25,000 lines. Above that the editor lags your typing.

The idle column is the surprising one

Look again at 50,000 lines: 28.57 ms even when you aren't typing.Nothing changed, and it still costs more than a frame.

Worth knowing: egui does cache the expensive part downstream. Itslayout_job is memoised, so handing it an identical job twice is cheap the second time. What isn't cached is building the job — your scanner — because that's your code and egui has never seen it.

Draw the line where the measurement is

Big files open instantly again, in plain text, and say why.

The table says highlighting is comfortable at 427 KB (7.11 ms while typing) and over budget at 1.1 MB (17.39 ms). So the limit goes between them, nearer the safe end.Two edits.

editor/src/main.rswith the other colours

const COMMENT: egui::Color32 = egui::Color32::from_rgb(0x8b, 0x92, 0x9c);

/// Above this size, highlighting costs more than a frame is worth. Chosen from
/// measurement: at 427 KB a keystroke costs 7.1 ms, at 1.1 MB it costs 17.4 ms,
/// and a 60fps frame is 16.7 ms.
const HIGHLIGHT_LIMIT: usize = 512 * 1024;

Second — the early exit, at the top of highlight:

editor/src/main.rsin fn highlight, before the scanner

    job.wrap.max_width = wrap_width;

    if text.len() > HIGHLIGHT_LIMIT {
        job.append(
            text,
            0.0,
            egui::TextFormat {
                font_id: font,
                color: PLAIN,
                ..Default::default()
            },
        );
        return ui.ctx().fonts_mut(|f| f.layout_job(job));
    }

    let mut rest = text;

One run, one colour, one append — which is exactly lesson 7 stage 1 again. The fast path was already written; it just needed a reason to exist.

Note font_id: font here, without .clone(). This branch uses the font once and then returns, so it can hand over ownership. The scanner below needs it on every iteration, which is why that one clones. The compiler enforces the distinction, and it's a small example of ownership doing useful work rather than being an obstacle.

cargo run --release -- big-50000.rs
→ opens instantly, plain text, ~7 ms/frame — back to lesson 6's numbers
cargo run --release -- big-10000.rs
→ still fully highlighted

Tell the user, don't just do it

The status bar says highlighting is off, so silence isn't mistaken for a bug.

An editor that silently stops highlighting looks broken. One that says "highlighting off (file too large)" looks considered. One edit.

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

        egui::Panel::bottom("status").show(ui, |ui| {
            let highlighting = if self.text.len() > HIGHLIGHT_LIMIT {
                "highlighting off (file too large)"
            } else {
                "highlighting on"
            };

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

Both branches produce a &'static str — text baked into the binary, borrowed, never allocated. There's no String here and noto_owned(), because there's nothing to own: the two messages exist for the whole life of the program.

cargo run --release -- big-50000.rs
→ … 2277780 bytes · highlighting off (file too large) · …

What we're deliberately not doing

The obvious next move is to cache the highlight so idle frames stop rescanning. I tried it before writing this lesson, and I'm not teaching it, for a reason worth reading:

Idle got five times better. Typing got four times worse — and when I measured the parts, the comparison cost 0.04 ms and the copy 0.11 ms, which does not come close to explaining the other 140. I don't yet know what does.

rm editor/big-*.rs
cargo fmt && cargo clippy
Both silent.