Performance
Evaluate performance against your application’s workload.
Your application needs a response-time budget for the complete API call. The recorded results here measure warm calculation and isolated execution on a specific rating workbook. Use them to examine those costs, then test your own model, traffic and deployment before setting service targets.
29.777 µs
rating-workbook evaluation, median of five round medians
73.125 µs
the same workbook with production isolation
185 formulas
in the rating workbook, with 21 outputs
240 cases
checked against recorded Excel results before timing
Recorded results
Calculation and isolation, measured separately.
A small two-core x86-64 test machine, with each measurement pinned to one core. These are warm calculation timings, alone and with isolation. They exclude HTTP, API request handling and the connection from the API to the calculation service.
| Workload and boundary | Median of round medians | Per-round p99 range |
|---|---|---|
| Rating workbook · evaluation | 29.777 µs | 34.171–38.754 µs |
| Rating workbook · isolated call | 73.125 µs | 97.346–111.421 µs |
| Synthetic workbook · evaluation | 27.717 µs | 32.847–38.132 µs |
| Synthetic workbook · isolated call | 76.309 µs | 90.672–100.611 µs |
Each row summarizes five rounds. The median is the median of those five medians. The p99 column gives the lowest and highest per-round p99; it is not a pooled percentile. Rating rounds contain 24,000 samples each, and synthetic rounds contain 102,400.
The insurance rater has 185 formulas and 21 outputs. The timed workbook is its rater-datevalue.xlsx variant, in which one cell that no selected output depends on differs, so both build the same calculation. All 240 cases match its recorded Excel results under the documented numeric comparison policy. It is a specific model, not a proxy for other workbooks or use cases.
The synthetic workbook has 10 inputs, 190 formulas and a separate 500-row lookup table. Its timed corpus contains 1,024 input sets. An absent-key case stays in the correctness checks and is excluded from timing under the recorded benchmark protocol. Synthetic expectations come from a specification, not an Excel validation stamp.
Test environment
The hardware and conditions behind the numbers.
-
Two-core x86-64 test machine
Each measurement was pinned to one core. The machine is not a sizing recommendation for your deployment.
-
Fixed memory limit
The measurement ran under a fixed memory limit and without network access. A limit is not a measurement of peak memory consumption.
-
Pinned build
Every round used the same pinned XSheet build, recorded with the results. The isolated measurements use the isolation production uses, not a simulation of it.
-
Correctness before timing
Ten warm-up passes precede 100 measured passes through each corpus. Five rounds record monotonic elapsed durations, machine conditions and build identifiers. The recorded run was completed on October 8, 2026.
Execution model
Ready before the request arrives.
-
Fast by design
Each workbook version is built once, before it serves calls, so a call never re-reads the workbook’s formulas.
-
Isolation stays in the measurement
The isolated-call rows include the full isolation that production uses. Reporting them separately makes the cost of isolation visible.
Workload evaluation
Benchmark the model you intend to use.
For a procurement decision, use representative workbooks, input distributions and the intended deployment configuration. Agree correctness and performance acceptance criteria before running the test.
-
Workbook complexity
Include models with 50,000 or 100,000 formulas when they represent your workload. Record lookup-table sizes, lookup types, dependency depth, input shapes and output count. These are evaluation scenarios, not measured results on this page.
-
Concurrent API traffic
Test 100 and 1,000 concurrent requests where required, alongside sustained arrival rates. Report successful throughput, errors, rejections and latency at p50, p95, p99 and p99.9. Concurrency is a load condition, not a capacity claim.
-
Cold and warm behavior
Measure the first request to an idle service separately from a warm request. Keep building a new version, starting a service and a full installation restart as separate measurements.
-
Resources and repeatability
Record peak memory, CPU use and the configured limits with the hardware and software versions. Repeat the run on an otherwise idle machine and retain the inputs and full result distribution.
Measurement scope
Use each result for the question it answers.
The recorded results above establish warm execution timings for two specific workbooks. They do not establish whole-API throughput, concurrent-request capacity, cold-start latency, p95, p99.9 or peak memory. Those measurements belong to the workload evaluation described above.
A reciprocal of a calculation timing is not HTTP throughput. A memory ceiling is not a memory footprint. Installation sizing should use measurements of the complete request path with your model and its expected traffic.
XSheet
See how your model would work as an API.
Discuss the workbook your team maintains and the applications that need its results. Explore integration and deployment in your environment.