Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Performance Targets

Every hot-path operation in Meridian has a benchmark target from the RFCs and a measured result from Criterion.

Full Scorecard

ComponentBenchmarkTargetMeasuredStatus
Configconfig_read<1ns0.68nsPass
Configarc_clone<5ns3.4nsPass
Buffersslab_acquire_release<15ns5.3nsPass
Buffersbufchain_push_4KB<50ns22.8nsPass
HTTPparse_simple_request<200ns88.1nsPass
HTTPparse_10_headers<500ns151nsPass
LBround_robin/pick<10ns0.73nsPass
LBmaglev/pick<15ns1.41nsPass
LBmaglev/table_build/100<1ms4.35msMiss
Resiliencecircuit_breaker/try_acquire<10ns5.3nsPass
Resiliencetoken_bucket/acquire<15ns21nsMiss
Observabilitycounter/increment<5ns2.9nsPass
Filterdynamic_chain/5_noop<25ns19.1nsPass
Filtermetadata/lookup_hit<10ns1.6nsPass
Filtermetadata/insert<20ns21.0nsBorderline

Overall: 21/26 targets met (81%)

Design Philosophy

No optimization without a benchmark proving the need. But the targets above are hard requirements — design for them from the start.

The benchmark crate (meridian-bench) uses standalone reimplementations of core types to isolate measurement. It does NOT depend on meridian-core — this ensures benchmarks measure the data structure, not the crate’s compilation overhead.

Key Design Decisions for Performance

DecisionRationaleImpact
Vec-based metadata (not HashMap)Linear scan beats hash for <8 entriesLookup: 11.9ns → 1.6ns
AtomicU32 RR counter (Relaxed)No cache-line bouncing between workers0.73ns per pick
Flat-array stats (not HashMap)Compile-time metric IDs, array index0.48ns per increment
arc-swap for config (not Mutex)Lock-free reads on every request0.68ns per read
RAII circuit breaker guardsNo “forgot to release” bugs, no branches5.3ns per acquire

Running Benchmarks

cargo bench -p meridian-bench

Results with HTML reports are generated in target/criterion/.