# Optimize the Operation That Repeats Not the One That Impresses ## Claim In a continuous-input workflow, the operation that fires constantly in the background sets the felt experience far more than the rare, foreground operation that makes a better demo, so a large improvement to the rare operation buys a headline number while the real daily-use win comes from shaving effort off the operation nobody watches. <!-- atomicity: 1 idea ✓ --> ## Scope & conditions - Applies wherever a workflow has both a high-frequency background operation (autosave, incremental build, a keystroke-triggered check) and a low-frequency foreground one (cold load, a full build, opening a file) — the high-frequency one dominates felt performance even when its per-instance improvement looks smaller in isolation. - Breaks down where the rare operation is a genuine adoption barrier — a slow first load can be the reason someone abandons a tool before ever reaching the repeated operation, in which case fixing the rare one is the higher-value work precisely because it's felt less often but gates everything after it. - The two numbers usually get reported with unequal confidence: a dramatic multiple on the rare operation ("tenfold faster") is more demo-able and more likely to be the headline, even when the smaller-sounding number on the repeated operation ("96% less save effort") is what a daily user will actually notice. ## Evidence > [!quote] > "Save effort has decreased in some cases by over 96% which is again huge huge performance improvement. This means less battery usage on your mobile device." Zsolt Viczián, releasing Obsidian Excalidraw 2.27.0 (2026-09-03), reports two separate performance numbers for the same release: a tenfold load-time improvement on image-heavy canvases (demoed live, the headline claim) and a 96%+ reduction in save effort, which he ties explicitly to tablet handwriting — where saves fire constantly and the improvement shows up as less battery drain, less heat, and fewer glitches. He volunteers, unprompted, that the load-time number only applies to cached images, narrowing his own headline claim against his interest. ## Links - [[3. Resources/Permanent Notes/The Bottleneck Moved From Code Generation to Review and Judgment]] — because contrasts: both concern identifying where the true constraint in a system actually sits rather than where the visible or demoable work is, one for engineering workflow and this one for runtime performance. - [[3. Resources/MOCs/Product & Startup Instincts MOC]] — because this is a product-prioritization heuristic — which improvement to make and which to lead with in communication — directly applicable to any product decision about where to spend optimization effort. - [[3. Resources/Permanent Notes/Running Work Less Often Can Raise the Worst Frame When Every Instance Shares One Schedule]] — extended by: Cutting how often a repeated job runs lowers total work, but if every instance moves to the same new schedule, the instances fire together and one frame takes the whole load. ## Tests / falsifiers - Instrument a workflow with both operation types and measure whether user-reported satisfaction tracks the frequency-weighted improvement or the raw magnitude of either single number — would directly test whether frequency dominates magnitude as the claim predicts. - Find a case where a rare-operation improvement measurably changed adoption or retention more than a repeated-operation improvement did — would identify the boundary condition (adoption barrier vs. daily-use quality) more precisely. ## Source - [[3. Resources/Readwise/Articles/Obsidian Excalidraw 2.27.0 Is HUGE Massive Speed Boost, Slideshow V4 & More!]] — Zsolt Viczián, YouTube release walkthrough, 2026-09-03. No benchmark methodology is given for either performance figure (no hardware, no baseline version, no measurement method); the improvements are almost certainly real and large, but the specific multiples are unverified.