Benchmarks

These benchmarks show typical render times, compare FSharp.ViewEngine with other F# view engines, and provide the commands needed to reproduce the results.

The representative page is a complete HTML document with metadata, navigation, content, lists, a form, a table, and a footer.

• Build and render: 1.585 μs for the representative page.
• Render only: 833.5 ns when the representative page is already built.
• Large response: 0.23 ms to build and render 1,000 repeated articles.

These are renderer operations, not HTTP requests per second. Routing, application work, I/O, concurrency, and response transport are not included.

For the representative build-and-render workload, the other engines take 1.35× to 2.35× as long as FSharp.ViewEngine. All four remain fast in absolute terms.

The current results were measured on August 6, 2026 with BenchmarkDotNet 0.15.8, .NET SDK 10.0.201, .NET runtime 10.0.5, macOS 26.4.1, and an Apple M5 Max Arm64 processor.

• Process isolation — every benchmark executes in a generated benchmark process rather than inside the runner.
• Repeated measurement — MediumRun uses two launches, ten warmups, and fifteen measured iterations.
• Bounded iteration time — a 100 ms target avoids multi-gigabyte allocation pressure in the fastest render-only cases.
• Render-only setup — documents are constructed once before warmup and measurement, keeping construction work out of the render loop.
• Reported values — tables show the arithmetic mean and managed allocation per operation; lower is better.

The comparison suite uses the latest stable releases checked for this measurement: Oxpecker.ViewEngine 2.0.1, Giraffe.ViewEngine 1.4.0, and Feliz.ViewEngine 1.0.3. The runner prints resolved package versions with every execution. Results are representative measurements, not CI regression thresholds.

Run commands from the solution directory. The FAKE targets forward trailing BenchmarkDotNet options, including filters. BenchmarkSmoke executes selected cases once in isolated processes to validate the suite without producing stable measurements.

cd sln

# Run the complete measurement suite.
./fake.sh Benchmark

# List or target benchmark cases.
./fake.sh Benchmark --list flat
./fake.sh Benchmark --filter '*Benchmarks.RenderOnly.*'

# Validate every case, or a filtered subset, once.
./fake.sh BenchmarkSmoke
./fake.sh BenchmarkSmoke --filter '*AttributeEncodingBenchmarks*'

The following tables preserve the raw mean and managed-allocation results behind the analysis above.

• Build-only CPU samples are dominated by TagBuilder.Run and generated computation-expression methods; sampled allocations are DOM nodes and overflow collections rather than closure objects.
• Render-only allocations are almost entirely the required returned System.String.
• Optimized ARM64 JIT output retains indirect child-render calls, but profiling does not identify dispatch as a dominant cost.
• General sequence input adds about 80 bytes and modest runtime overhead, which does not justify collection-specific overloads.
• Measurements continue to support inline storage for zero, one, and two attributes or children.
• The renderer retains at most one thread-static string builder no larger than 256K characters, bounding retained memory without regressing the representative large response.