cppdjango 6.0.7.post1 / evidence
← About cppdjango
CPU benchmark summary
Headline calculation, per-operation CPU, PostgreSQL attribution, construction cost, correctness totals, and method.
Open benchmark-summary.json →Public performance artifact ledger
Every number behind cppdjango’s performance claims.
This directory is the public evidence bundle for the native implementation released as cppdjango 6.0.7.post1. It contains the final worker and database CPU samples, construction timings, prefork COW validation, boundary audit, measurement drivers, and exact measured source patch.
36final raw-cursor and ORM worker CPU samples
18matched dedicated PostgreSQL task-CPU samples
112raw QuerySet construction observations
Start here
Human-readable first. Raw counters one click away.
The summary JSON contains the published values and calculation. The CSV files preserve the individual observations used to derive them.
Worker CPU records
All 36 final alternating raw-cursor and ORM runs with operation counts, wall time, user/system CPU, faults, and context switches.
Open cpu-process.csv →PostgreSQL task CPU
Eighteen final records sampling the dedicated PostgreSQL backend at the exact worker measurement boundaries.
Open cpu-postgresql.csv →QuerySet construction samples
Two independent seven-sample runs for manager, projection, point-filter, and ordered-IN32 construction.
Open construction.csv →Python/C++ entries
The terminal boundary, zero Python metadata/preparation hooks, PostgreSQL integer OID handling, and fallback contract.
Open boundary-audit.json →Exact measured patch
The source diff loaded by the final CPU and equal-work memory runs. Its SHA-256 is in the checksum ledger.
Open measured-source.patch →CPU measurement driver
The deterministic raw and ORM operations, warmup, process-clock boundaries, and machine-readable output.
Open profile_postgresql_orm_cpu.py →Checksum ledger
SHA-256 digests for every downloadable artifact in this directory, excluding the ledger itself.
Open SHA256SUMS →Memory and prefork COW
The final native binder keeps COW at parity.
After exactly 300,032 successful requests on 16 preloaded workers per implementation, cppdjango dirtied 724 KiB fewer pages and recorded 165 fewer minor faults. Total USS was 2.25 MiB lower; total PSS was 2.71 MiB higher because the extension remains shared. The earlier three-repeat lazy/preload study remains below as deployment context.
Current COW result
The final schema-and-binder build, exact request count, aggregate memory deltas, fault deltas, and throughput context.
Open memory-final-validation.json →Current aggregate samples
Path- and PID-free master, worker, and whole-service snapshots before and after equal work.
Open memory-final-snapshots.csv →Current equal-work records
Both 16-worker legs completed 300,032 requests with zero errors.
Open memory-final-load.csv →Lazy versus preload study
Paired medians, PSS and USS deltas, preload savings, COW proxies, definitions, and source identities.
Open memory-summary.json →Master and worker snapshots
Every aggregate PSS, USS, shared-page, private-dirty, and fault snapshot across all repetitions.
Open memory-snapshots.csv →Anonymized process records
All master and worker samples with stable indexes instead of operating-system process identifiers.
Open memory-processes.csv →Memory-run load records
Twelve order-alternated legs, each completing exactly 300,032 requests with zero failures.
Open memory-load.csv →Memory methodology
The result, fair-work correction, fork modes, counter definitions, interpretation, and limitations.
Open memory-methodology.md →PSS and COW collector
The Linux smaps-rollup and process-fault collector used for every master and worker snapshot.
Open profile_uwsgi_memory.py →Exact measured harness
The uWSGI lifecycle, alternating run order, fixed-work client, identity checks, and artifact capture.
Open run_uwsgi_postgresql_memory.sh →Memory result summarizer
The validator and reducer that produces the public summary and hostname-free aggregate tables.
Open summarize_uwsgi_memory.py →Memory-run source patch
The exact cppdjango source diff loaded by the measured workers, including the current regression tests.
Open memory-measured-source.patch →Siege connection profile
HTTP/1.1 keep-alive, disabled parsing, and benchmark-mode settings for the exact-request run.
Open siege_memory.conf →Balanced request rotation
The three-path rotation used to identify and correct the fixed-duration memory comparison bias.
Open uwsgi_memory_mix.lua →Earlier instruction-parity audit
Archived hardware-counter captures.
These captures predate the final schema-and-binder pass and are not inputs to the 436% headline. They remain useful evidence that identical SQL shapes retire nearly identical PostgreSQL instructions. The final database attribution above uses directly sampled task CPU.
Worker processes
Reading the evidence
What each measurement includes.
The separation matters: process CPU is not request latency, and PostgreSQL CPU is not included in the 436% framework-only headline.
Django connection and cursor management, psycopg, protocol/TLS work charged to the client, and row decoding. No ORM query compiler.
ORM worker CPU minus that implementation’s matched raw cursor CPU. The balanced headline sums one point select, one IN32, and one update.
Dedicated backend task ticks read from procfs at the same start and end boundaries as worker CPU. Earlier hardware counters remain an independent SQL-work parity audit.
Worker and backend task CPU added from separate matched runs. Useful as an approximate demand total, not an elapsed-time measurement.
$ curl -s https://django.goblinreactor.com/artifacts/benchmark-summary.json $ curl -O https://django.goblinreactor.com/artifacts/cpu-process.csv $ curl -O https://django.goblinreactor.com/artifacts/cpu-postgresql.csv $ curl -O https://django.goblinreactor.com/artifacts/construction.csv $ curl -s https://django.goblinreactor.com/artifacts/memory-final-validation.json $ curl -O https://django.goblinreactor.com/artifacts/measured-source.patch