METHODOLOGY
The method behind each result.
Lab measurements, industry evidence and assumptions are different. We show their sources and limits.
Four kinds of evidence
LAB
A controlled before/after measurement using the same task and data, with environment, repetitions, method, code and raw results.
CLIENT
An anonymized real measurement published with client approval. Repository and raw data links are not shared.
INDUSTRY
Research from another organization. Dates, denominators and limitations remain visible; these are not our results.
ASSUMPTION
An editable starting value for a model. It is neither a measured saving nor a quote.
Each chart identifies its source; each calculation explains its assumptions.
Measurement protocols
Order-report duration using the same bytecode
1,000–1,000,000 records, two runtimes and ten fresh JVMs per point. An independent Python oracle checks equal output; median per-report duration is reported.
The same bytecode is compiled once by Java 8 javac; Corretto 1.8.0_432-b06 and 25.0.3+9-LTS on native arm64 Apple M3 with 24 GiB RAM. Each JVM uses -Xms256m -Xmx256m -XX:+UseG1GC, 5 s warmup and at least 1 s measurement. Data generation is outside the window; scanning, grouping, checksums and harness-loop overhead are inside. elapsedNanos/batches is the per-run report duration; the median of ten runs is shown. All seven sizes and repetitions are retained. Shared desktop, short windows and different patch levels are limitations; this is not JMH or a production capacity test.
Open the measurement script ↗Stop searching the full catalog for every row.
Match product codes in an order import against a 10,000-product catalog. Same .NET version and output; keyed access instead of repeated list scans.
Identical catalog and import rows on the same .NET 10 runtime. Two warmups and ten measurements per arm and size; 108 observations in total. End-to-end duration includes index construction and output-array creation. Input generation, pre-run GC and output SHA-256 are outside every arm. An independent Python business-rule oracle checks the little-endian int64 output hash, count, missing SKUs and cent total. CPU uses the Linux process CPU clock; memory is managed allocation delta. The primary point is the preselected 50,000 rows.
Open the measurement script ↗50,000 invoices. Render the rows the screen needs.
Filter overdue invoices. Identical records and scrollable range; a different number of rows rendered at once.
Alternating implementations in a visible browser tab. Two warmups followed by 10 runs per implementation and size. Verify the complete matching result checksum, top/bottom viewport and scroll height. Timing starts before filtering and includes DOM, layout and two requestAnimationFrame callbacks; it does not instrument physical screen presentation. Primary point: 50,000 source invoices.
Open the measurement script ↗One order, three services. Stop stacking the waits.
Prepare an order using price, stock and shipping responses. We measured runtime migration and concurrent workflow changes separately against identical order results.
Same Java 8 bytecode on both JDKs, identical synthetic outputs and dependency service. Sequential pool of 8, Java 25 runtime-only control and matched 64-call platform/virtual arms. Additional dependency-capacity-8 control; all 140 runs published. Primary point of 256 orders selected before measurement. Duration covers complete batch completion; platform threads are the median ThreadMXBean peak.
Open the measurement script ↗Stop reading the same orders again and again.
Order totals by customer. Same PHP version, same data, same output; a different way to compute it.
Identical PHP/SQLite versions, synthetic records and 200 customers. Two warmups then 10 runs per arm/size; every complete output matches an independent oracle. PHP lookup totals rebuilt each run. SQL timings are warm in-memory reads excluding loading/index creation. Index bytes and the single construction observation are separate. Primary 200,000-record point selected before measurement.
Open the measurement script ↗500 customer balances from 5 million orders.
Run the same open-order balance report. Business rules and engine stay the same; the access path that scans the whole table per customer changes.
Open-order totals for 500 customers using deterministic synthetic integer cents. Three sizes and three arms fixed before measurement. Identical SQL before/after indexing plus a grouped-query control. Two warmups then ten repetitions with rotating arm order. All 500 output rows match an independent oracle every time. Reads exclude loading, index construction and validation; two new in-memory databases per size, warm repetitions. Write workload and monetary billing effects were not measured.
Open the measurement script ↗Find the rows you need without scanning the whole table.
Open order totals by customer. The same query before and after indexing, on the same SQLite engine.
Identical PHP/SQLite versions, synthetic records and 200 customers. Two warmups then 10 runs per arm/size; every complete output matches an independent oracle. PHP lookup totals rebuilt each run. SQL timings are warm in-memory reads excluding loading/index creation. Index bytes and the single construction observation are separate. Primary 200,000-record point selected before measurement.
Open the measurement script ↗What accompanies a published measurement?
Published lab cases link to a repository and raw measurement file. Each result shows its repetition count and median or mean. Unknown values stay unknown; a timeout is not displayed as a completed result. Client data and synthetic data are different.
Calculator assumptions and rationale
Cautious, Moderate and Optimistic are scenarios. You can change their rates to suit your situation. The starting values are not derived from industry statistics; they are editable assumptions for comparison.
Cautious
- A 20% maintenance-cost reduction in the cautious scenario is a scenario assumption you can adjust.
- A 30% licence and infrastructure-cost reduction in the cautious scenario is a scenario assumption you can adjust.
- A 40% downtime-cost reduction in the cautious scenario is a scenario assumption you can adjust.
- A 50% manual-work cost reduction in the cautious scenario is a scenario assumption you can adjust.
- A 5% annual existing-system cost increase in the cautious scenario is a scenario assumption you can adjust.
Moderate
- A 35% maintenance-cost reduction in the moderate scenario is a scenario assumption you can adjust.
- A 50% licence and infrastructure-cost reduction in the moderate scenario is a scenario assumption you can adjust.
- A 60% downtime-cost reduction in the moderate scenario is a scenario assumption you can adjust.
- A 70% manual-work cost reduction in the moderate scenario is a scenario assumption you can adjust.
- A 10% annual existing-system cost increase in the moderate scenario is a scenario assumption you can adjust.
Optimistic
- A 50% maintenance-cost reduction in the optimistic scenario is a scenario assumption you can adjust.
- A 70% licence and infrastructure-cost reduction in the optimistic scenario is a scenario assumption you can adjust.
- An 80% downtime-cost reduction in the optimistic scenario is a scenario assumption you can adjust.
- An 85% manual-work cost reduction in the optimistic scenario is a scenario assumption you can adjust.
- A 15% annual existing-system cost increase in the optimistic scenario is a scenario assumption you can adjust.
Change log: 13 October 2026 — initial model and three scenarios recorded. 14 October 2026 — explanations linked from this page; rates unchanged.
Open the formulas and calculator →How we use AI
AI assists discovery, documentation and draft code. People own design decisions, validation, code review and release decisions. Case steps distinguish human and AI contributions. Client data is not sent to an external model without authorization; data, service, masking and access boundaries are agreed first.
How replay works
When a real case is published, replay uses only recorded test points. Visuals are illustrated; durations and outcomes come from the measurement file. The smallest 1–2–5 factor that fits the old system into 20 seconds, or 6 seconds on the home page, applies to both systems. Reduced motion shows the result directly.
Corrections
To report an error, include the page, the claim and a primary source if available. Verified corrections are reflected in the content and its update date.
hello@rearchlabs.com