Avoid rescanning files for every inline hunk

AI-assisted change (OpenAI Codex).

Author: Wilfred

PERF_RESEARCH_LOG.md

@@ -9,11 +9,12 @@ revert it if it doesn't, write down the outcome either way.
 
 ## Harness
 
-`perf(1)` is not installed in this sandbox and its counts are noisy anyway, so
-the metric is callgrind's `Ir` — the same quantity `perf stat` reports as
-`instructions:u`, but counted by emulation rather than sampled from the PMU.
-Repeated runs of the same binary on the same input agree to the instruction,
-which means a 0.3% win is a real 0.3% win and needs no repeat runs.
+Both `perf` and callgrind are available in the current environment. The fast
+iteration metric is repeated `perf stat -e instructions:u`; callgrind's `Ir`
+counts the same quantity by emulation and is used when deterministic attribution
+or a fixed-suite comparison justifies its roughly 40x slowdown. Repeated
+callgrind runs of the same binary agree to the instruction, while `perf` runs
+are reported as a distribution or median.
 
 | script | purpose |
 | --- | --- |
@@ -726,6 +727,29 @@ comparison of the 22 MB `huge_cpp` pair. Haskell remains unavailable because
 of the unchanged baseline abort from exp9. `cargo test --release` passes (157
 passed, one ignored).
 
+### exp15: calculate inline line bounds once per file — KEPT
+
+Inline rendering computed each input's maximum line number once to determine
+the line-number column width, but then rescanned both complete input strings
+inside every hunk when calculating after-context. With `h` sparse hunks in an
+`n`-byte file, that made this part of inline display O(nh).
+
+The renderer now retains the two line numbers it already needs for column
+widths and passes them to every context calculation. On a synthetic 20,000-line
+text pair with every tenth line changed, `--display inline --context 0`
+produces 2,000 separate hunks. Three individual `perf stat` runs gave:
+
+| implementation | instruction counts | median | change |
+| --- | --- | ---: | ---: |
+| rescan both files per hunk | 17,610,740,476; 17,610,721,413; 17,610,524,215 | 17,610,721,413 | |
+| calculate each maximum once | 1,719,749,762; 1,719,473,867; 1,719,496,131 | 1,719,496,131 | **-90.2%** |
+
+This path is only reached by inline display, so the default side-by-side
+callgrind suite was not run. Output is byte-identical in side-by-side colour,
+inline, and JSON modes on all 108 measurable sample pairs, including the 22 MB
+`huge_cpp` pair. Haskell remains unavailable because of the unchanged baseline
+abort from exp9. `cargo test` passes (157 passed, one ignored).
+
 ## Where this leaves things
 
 | pair | master | now | change |

plan.md

@@ -164,6 +164,13 @@ suite. After the kept changes: **16,586,352,574**, i.e. **-42.5%**.
 | 6 | skip stale entries when popping the Dijkstra heap | +0.2% | rejected |
 | 7 | pack the vertex identity into two words | -0.7% | kept |
 | 8 | key the `seen` map by that packed key | -1.9% | kept |
+| 9 | replace each `seen` value's `SmallVec` with two exact slots | -1.18% on current 26-pair suite | kept |
+| 10 | compute a vertex key before constructing the candidate | +0.38% on search probes | rejected |
+| 11 | build syntax spans directly from tree-sitter points | -1.44% on current 26-pair suite | kept |
+| 12 | mixed-Unicode display-width fast paths | +0.68% or incorrect output | rejected |
+| 13 | insert visible line ranges once per hunk | -96.6% on a 12k-line full rewrite | kept |
+| 14 | group JSON changes by line before rendering | -82.6% on a 12k-line full rewrite | kept |
+| 15 | calculate inline line bounds once per file | -90.2% on a 20k-line/2k-hunk diff | kept |
 
 The last completed experiment is committed. `results/` holds a labelled `.tsv`
 per experiment, so a new callgrind suite run should normally be compared
@@ -176,29 +183,24 @@ Ordered by how much is left on the table. The suite is now dominated by
 `typing` (3.12G), `slow` (2.17G), `modules` (2.13G), `long_line` (1.74G) and
 `objc_module` (1.52G).
 
-1. **More of `allocate_if_new`.** Still the single hottest function: 33% of
-   `slow.rs`, 3.47M calls at ~215 instructions each before exp7 and exp8 took
-   about a fifth off that. The remaining idea is to avoid *constructing* the
-   64-byte `Vertex` at all on a hit — `compute_neighbours` builds one for each of up to seven neighbours
-   and `allocate_if_new` discards most of them. The key can be computed from
-   the same inputs before the struct is built. This is a real refactor of the
-   seven construction sites, not a micro-edit.
-2. **`line_numbers::LinePositions::from_region`** — 86M (2.75%) on `typing.ml`,
-   plus its `Vec` allocation per call. Two binary searches per call, and
-   difftastic calls it with offsets that increase monotonically as it walks the
-   tree. A local wrapper caching the last line index would make it O(1)
-   amortised. `line-numbers` is Wilfred's own crate, so upstreaming is an
-   option.
-3. **The remaining tree-sitter query analysis.** After exp1 and exp3 a trivial
+1. **`compact_gaps` on large single-sided runs.** It removes index zero from a
+   `Vec` while pairing pending lines, which shifts the remaining elements on
+   every removal. Profile a synthetic insertion/deletion large enough to make
+   that path dominant, then test a `VecDeque` or cursor-based implementation.
+2. **The remaining tree-sitter query analysis.** After exp1 and exp3 a trivial
    Rust diff is 206M instructions, still ~80% `ts_query__perform_analysis`. The
    ablation in the log shows it's four `scoped_identifier`/`scoped_type_identifier`
    patterns costing ~132M between them, and they genuinely affect output, so
    they can't just be dropped. Ideas not yet tried: whether `@type` captures
    are needed at all when `--color=never` (they only affect display colour,
    unlike `@comment`/`@string` which change the diff itself); whether a newer
    tree-sitter analyses faster.
-4. **`split_string_by_width` and the display path** — still 10% of
+3. **`split_string_by_width` and the display path** — still 10% of
    `long_line` after exp4.
+4. **Graph search after exp9.** `mark_syntax`, `allocate_if_new`, and
+   `compute_neighbours` remain the leading costs on `slow`; exp10 showed that
+   merely decomposing candidate construction makes the hot path worse, so the
+   next attempt needs to remove larger-grained work or improve the algorithm.
 5. **Ideas that change output** — better pre-diff splitting, skipping unique
    atoms — are listed in `PRIOR_WORK.md`. They can't go through this loop as
    set up, because `check_output.sh` would reject them by construction. They

src/display/inline.rs

@@ -64,9 +64,11 @@ pub(crate) fn print(
     let opposite_to_lhs = opposite_positions(lhs_mps);
     let opposite_to_rhs = opposite_positions(rhs_mps);
 
-    // Calculate the maximum line number width for alignment
-    let lhs_line_nums_width = format_line_num(lhs_src.max_line()).len();
-    let rhs_line_nums_width = format_line_num(rhs_src.max_line()).len();
+    // Calculate the maximum line number width for alignment and context.
+    let lhs_max_line = lhs_src.max_line();
+    let rhs_max_line = rhs_src.max_line();
+    let lhs_line_nums_width = format_line_num(lhs_max_line).len();
+    let rhs_line_nums_width = format_line_num(rhs_max_line).len();
 
     for (i, hunk) in hunks.iter().enumerate() {
         println!(
@@ -93,9 +95,8 @@ pub(crate) fn print(
             &[&before_lines[..], &hunk_lines[..]].concat(),
             &opposite_to_lhs,
             &opposite_to_rhs,
-            // TODO: repeatedly calculating the maximum is wasteful.
-            lhs_src.max_line(),
-            rhs_src.max_line(),
+            lhs_max_line,
+            rhs_max_line,
             display_options.num_context_lines as usize,
         );