sqlite-memory
144 samples
- DivergenceV3 3.2.0 86.0 ms
- Started
- Generated
- Measured samples
- 144
- Combinations
- 1
Machine
Captured from the runner's system manifest.
Host
eimu
Linux · kernel 6.19.6
PHP
8.5.3
Processor
AMD Ryzen 9 5950X 16-Core Processor
32 cores · x86_64
Memory
31.2 GB
DIMM_A2 16 GiB 2666 MT/s DDR4 F4-4266C19-16GVK
DIMM_B2 16 GiB 2666 MT/s DDR4 F4-4266C19-16GVK
Disk
3.5 TB
Device: /dev/nvme0n1
Capacity: 3.5 TB
Runtime envelope
End-to-end time per scenario run across all non-warmup samples.
- Min sample
- 10.6 ms
- Mean sample
- 86.0 ms
- Max sample
- 330 ms
- Cumulative time
- 12.384s
- Throughput
- 11.628/s
Runtime comparison
Mean time per scenario run in this upload, warmup runs excluded, sorted by runtime.
Where the time goes
Each bar is one framework's mean scenario run, split into its phases and sorted by total. Bars share a scale within each engine. Hover a bar for the numbers.
Init
Insert
Read
Update
Delete
Mean split across 1 combinations
sqlite-memory
- DivergenceV33.2.0 86.0 ms
Exact numbers
| DivergenceV3 3.2.0 | sqlite-memory | 144 | 86.0 ms | 19.2 ms | 16.7 ms | 45.3 ms | 3.97 ms |
|---|
Scenario families
Mean across every framework and engine in this upload.
What the workloads measure
The row shape and operation mix decide where each framework spends its time.
Scenario families
- simple baseline row shape
- Shows framework overhead with minimal field complexity, so object creation and query setup dominate.
- canary mixed field and nullable stress
- Wide mixed records amplify casting, hydration, dirty tracking, and adapter metadata overhead.
- int_fixed pure scalar writes
- A low-noise floor. Slow results here usually mean framework machinery is expensive even before text and cast-heavy payloads show up.
- float_fixed numeric conversion paths
- Decimal and float normalization can widen update and verification cost, especially for ORMs that compare serialized values.
- string_fixed predictable text hydration
- Column count and text assignment matter more than payload variability, which makes hydration strategy easier to isolate.
- string_variable application-like text workload
- Variable strings and note fields make this the closest to real CRUD traffic and usually punish heavier active-record layers the most.
Operation shapes
- Warmup vs hot runs
- Run 1 is warmup. Hot-path averages exclude it so boot and metadata setup do not dominate steady-state rankings.
- Insert and indexed schemas
- Indexed tables make writes cost more because every insert and many updates must maintain secondary indexes as well as the row itself.
- Read all vs read probes
- Read All rewards bulk hydration efficiency; random and tail probes expose per-query setup, lookup overhead, and tiny-result inefficiency.
- Update with verification
- Each update shape is followed by a verification read, so dirty-checking, write SQL generation, hydration, and comparison all affect the final time.
- Delete with confirmation
- Deletes are checked afterward. Frameworks that pay extra for follow-up lookups or teardown lose more time here than a bare SQL path.
- Total runtime
- The total runtime metric is effectively a benchmark of the machine plus adapter behavior across the full workload, not just one CRUD verb.