Benchmark without overclaiming
Dexpot makes interpreter-adaptive execution a design goal, but this repository does not establish a universal speedup over other frameworks. A single machine, one run, or an invalid-response count alone is not comparative evidence. The recorded loopback example is explicitly exploratory and client-observed; do not generalize its numbers to production or framework processing time.
Define the question and boundary
Section titled “Define the question and boundary”Before measuring, record the question (for example, sustainable successful requests at a target latency), Python build and GIL state, Dexpot revision, OS/hardware, parser mode, pool/queue/worker settings, route/body, generator version and settings, duration, warm-up, and repetition plan. State whether latency includes client scheduling, TCP loopback, HTTP parsing, routing, handler execution, encoding, and response transfer. wrk client latency includes its own scheduling and transport; it is not isolated server CPU time.
Compare only equivalent work: same response status and bytes, request method/body, connection policy, concurrency, keep-alive, runtime/build, host conditions, and validation. Include successful-response correctness checks; a fast server returning wrong or missing bodies is not a valid result.
Run a correctness-matched local experiment
Section titled “Run a correctness-matched local experiment”Use the checked-in minimal.py and the repository’s dexpot-loopback.lua validator. The script requests GET /items/7 and checks status 200 plus the exact body {"id":7,"name":"item-7","price":7.0}; mismatched status or body increments the invalid count.
uv sync --all-extrasDEXPOT_HTTP_PARSER=python DEXPOT_EXAMPLE_PORT=8000 uv run python examples/minimal.py# In a second terminal, from the repository root:wrk -t2 -c16 -d30s --latency -s website/benchmarks/dexpot-loopback.lua http://127.0.0.1:8000Repeat with a fixed, disclosed matrix and independent runs; retain raw output and report errors alongside latency distributions and throughput. Stop unrelated local load. Do not present the connection count or test duration as production capacity. For cross-framework claims, publish equivalent application and generator code plus environment, exact versions, commands, raw results, and correctness validation. Prefer omitting a comparative claim when the workloads or measurement boundaries cannot be matched.
Interpret scheduler and parser experiments
Section titled “Interpret scheduler and parser experiments”Record sys._is_gil_enabled() where available and the exact Python build; distinguish a standard GIL build from a free-threaded build. Report DEXPOT_POOL, DEXPOT_MAX_QUEUE, DEXPOT_MAX_CONNECTIONS, and DEXPOT_WORKERS. Queue and active-connection capacity are per process except the free-threaded active-connection semaphore, which is process-wide within the single process. A worker fan-out multiplies per-worker GIL capacity; it is not a single global queue.
Compare DEXPOT_HTTP_PARSER=python and native only when the optional extension is installed and both produce identical accepted/rejected behavior. The native extension parses request heads only; it does not move sockets or handler work to Rust. Parser throughput alone is not whole-server throughput.
The existing loopback record is one exploratory 5-second run with its own stated boundary, not a regression threshold or reproducible cross-product benchmark. See the execution model for what the selected scheduler actually does.