---
title: Performance
description: How Curb achieves parse-floor performance, and why that matters for running inside every build.
url: https://docs-v3-preview.elastic.dev/design-principles/performance
---

# Performance
Measured on a 6.5 MB corpus (1,196 files), as CPU time:

|                                                       |                |
|-------------------------------------------------------|----------------|
| Roslyn parse + full red tree — the floor for any tool | **~300 ms**    |
| **Curb**                                              | **~350 ms**    |
| `dotnet format whitespace`                            | **~12,000 ms** |

Parsing is about 2.5% of the budget. Roughly 97% of what a formatter costs is its own work. Curb adds almost nothing on top of the parse: it is within measurement noise of the floor.
The [twelve-repository comparison](https://docs-v3-preview.elastic.dev/benchmarks) has wall-clock numbers across real repositories; on roslyn (17,167 files) Curb takes **7 s** against `dotnet format whitespace`'s **34 s**.

## Why it is fast

The document IR lives in a pooled struct arena — structs, not objects, reusing memory across files. Curb loads no workspace and resolves no symbols. The conditional round-trip reparse (see [Safety](https://docs-v3-preview.elastic.dev/design-principles/safety)) means most files pay for one parse, not two.
It ships as a native-AOT binary per platform, so there is no JIT warm-up: about 10 ms to start.

## Why parse-floor speed matters

The build integration runs Curb before `CoreCompile`. If formatting costs more than parse time, the build slows down. Because Curb adds almost nothing beyond the parse, a build with Curb is a build without it — measured rather than assumed.
On unchanged projects the MSBuild stamp means no process starts at all. The performance number is for the case where work actually happens.