[vedanth-jadhav]

Timeline mapping resolves each clip's outgoing transition with effective_transition(index + 1), then repeats that lookup as the next clip's incoming transition. This repeats the binary search and duration validation/clamping on frame lookups used by playback, audio mapping, and rendering.

Carry the already resolved outgoing transition into the next iteration. Three production lines change; the no-transition fast path and mapping arithmetic are unchanged. No public API, allocation, persistent cache, or invalidation rule is added.

Release measurements

Baseline 1b614d9c0, Linux x86_64, AMD EPYC 9V74, two-CPU quota, CPU 0 affinity, Rust 1.88.0. Root release profile (opt-level=s, thin LTO, one codegen unit). Five alternating independent processes per version; 25 samples after three warmups, 1,024 public get_frame_mapping calls per sample. Medians of process medians:

Clips	Transitions	Before / mapping	After / mapping	Reduction
20	None, unchanged control	29.869 ns	29.879 ns	-0.03%
20	Every boundary	282.526 ns	167.562 ns	40.7%
20	Every fourth boundary	116.793 ns	81.820 ns	29.9%
100	Every boundary	1,611.655 ns	847.823 ns	47.4%
100	Every fourth boundary	812.557 ns	469.932 ns	42.2%
1,000	Every boundary, stress case	21,068.062 ns	11,050.594 ns	47.5%

Fixtures use different source offsets, clip lengths, speeds, recording clips and transition types. Queries cover the timeline evenly; output slots are reused. Fixture construction and complete result fingerprinting are outside timing. Every baseline/head fingerprint matches. The 1,000-clip case is a stress test. These are small absolute CPU savings per frame and do not establish an end-to-end playback/export speedup. Full native GPUI/GPU execution was not benchmarked.

An additional package-only optimization-level-3 control (--config profile.release.package.cap-project.opt-level=3, dependencies otherwise retain the root release profile) also shows 31.8–46.5% reductions across the transition cases. The 100-clip dense case is 1,521.503 → 823.001 ns per mapping; the no-transition control is 21.223 → 21.154 ns. This uses the same five-process/25-sample protocol, and all fingerprints match both the baseline and the size-optimized runs. It measures this function at level 3, without claiming a full GPUI build or whole-app speedup.

Correctness and validation

A normal test passes on both the original and optimized implementations. It derives expected mappings from independently computed clip offsets and checks exact source-time bits, segment identities, transition progress, durations and output boundaries. It covers eight consecutive clips with speed changes, adjacent/sparse transitions, half-clip duration clamping, zero/NaN/infinite durations, and ignored first/out-of-range transitions. Start, midpoint and end-adjacent positions are checked; negative time, timeline end, NaN and infinity remain unmapped. Existing hold/transition composition and legacy no-transition tests also pass.

• cargo fmt --all --check
• cargo check -p cap-project --locked
• cargo test -p cap-project --locked: 179 library and 4 integration tests pass; 4 existing benchmarks ignored.
• cargo clippy -p cap-project --all-targets --locked -- -D warnings
• git diff --check

Reproduction

Copy the example onto both revisions, build separately, save the binaries, then alternate five runs each:

cargo build -p cap-project --release --locked --example transition-mapping-benchmark -j 2
taskset -c 0 target/release/examples/transition-mapping-benchmark

The example prints per-sample nanoseconds per mapping and complete mapping-result fingerprints. The source example is included so these measurements can be reproduced on the baseline and head.

Per-process medians (nanoseconds per mapping)

Clips / transition stride	Before (five runs)	After (five runs)
20 / 0	29.878, 29.869, 29.849, 29.819, 30.279	29.966, 29.879, 29.927, 29.869, 29.790
20 / 1	286.644, 282.526, 282.213, 281.989, 318.507	167.093, 167.562, 168.374, 166.593, 170.857
20 / 4	116.921, 116.265, 116.628, 116.793, 143.482	81.742, 81.820, 81.781, 81.947, 84.108
100 / 1	1669.915, 1609.200, 1574.579, 1611.655, 1840.304	845.691, 927.609, 847.539, 859.022, 847.823
100 / 4	867.276, 812.557, 798.874, 801.017, 853.506	508.993, 553.845, 469.932, 468.876, 469.922
1000 / 1	21224.251, 19974.515, 20234.761, 21464.350, 21068.062	11188.327, 11050.594, 10862.855, 10840.353, 11261.608

Confidence Score: 5/5

The PR appears safe to merge; the reused transition preserves the existing mapping behavior.

Summary

Reuses each clip’s resolved outgoing transition as the next clip’s incoming transition.

• Timeline mapping reuses each transition at the next clip.

_{Reviews (2) · Last reviewed commit: "Merge branch 'main' into perf/reuse-adja..." · Reviewed by Greptile}

[vercel]

Someone is attempting to deploy a commit to the Cap Software Inc Team on Vercel.

A member of the Team first needs to authorize it.

[vedanth-jadhav]

Ready to merge? @richiemcilroy
It's my first pr 😭

[vedanth-jadhav]

@greptileai review