- Started
- Generated
- Measured samples
- 1,872
- Combinations
- 13
Machine
Captured from the runner's system manifest.
Host
kaiju
Linux · kernel 6.19.8-200.nobara.fc43.x86_64
PHP
8.5.11
Processor
Intel(R) Xeon(R) CPU E5-2687W v4 @ 3.00GHz
48 cores · x86_64
Memory
251.7 GB
P1_DIMMA1 32 GB 2133 MT/s DDR4 M386A4G40DM0-CPB
P1_DIMMB1 32 GB 2133 MT/s DDR4 M386A4G40DM0-CPB
P1_DIMMC1 32 GB 2133 MT/s DDR4 M386A4G40DM0-CPB
P1_DIMMD1 32 GB 2133 MT/s DDR4 M386A4G40DM0-CPB
P2_DIMME1 32 GB 2133 MT/s DDR4 M386A4G40DM0-CPB
P2_DIMMF1 32 GB 2133 MT/s DDR4 M386A4G40DM0-CPB
P2_DIMMG1 32 GB 2133 MT/s DDR4 M386A4G40DM0-CPB
P2_DIMMH1 32 GB 2133 MT/s DDR4 M386A4G40DM0-CPB
Disk
447.1 GB
Device: /dev/sda
Capacity: 447.1 GB
Runtime envelope
End-to-end time per scenario run across all non-warmup samples on mariadb.
- Min sample
- 85.0 ms
- Mean sample
- 1,198 ms
- Max sample
- 8,144 ms
- Cumulative time
- 37m 22s
- Throughput
- 0.835/s
Runtime comparison
Mean time per scenario run in this upload, warmup runs excluded, sorted by runtime.
Init
Insert
Read
Update
Delete
- PHPFUIBatch 3.0.3 mariadb 627 ms
- Doctrine 3.6.2 mariadb 829 ms
- Cycle 2.16.0 mariadb 936 ms
- Atlas 2.0.1 mariadb 941 ms
- PHPFUI 3.0.3 mariadb 1,050 ms
- Propel2 6cb272b6 mariadb 1,091 ms
- CakeCached 5.3.3 mariadb 1,168 ms
- DivergenceV2 2.1.4 mariadb 1,170 ms
- Cake 5.3.3 mariadb 1,187 ms
- DivergenceV3 3.2.0 mariadb 1,307 ms
- Yii 2.0.54 mariadb 1,336 ms
- RedBean 5.7.5 mariadb 1,686 ms
- Eloquent 13.2.0 mariadb 2,242 ms
Where the time goes
Each bar is one framework's mean scenario run on mariadb, 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 13 combinations
mariadb
- PHPFUIBatch3.0.3 627 ms
- Doctrine3.6.2 829 ms
- Cycle2.16.0 936 ms
- Atlas2.0.1 941 ms
- PHPFUI3.0.3 1,050 ms
- Propel26cb272b6 1,091 ms
- CakeCached5.3.3 1,168 ms
- DivergenceV22.1.4 1,170 ms
- Cake5.3.3 1,187 ms
- DivergenceV33.2.0 1,307 ms
- Yii2.0.54 1,336 ms
- RedBean5.7.5 1,686 ms
- Eloquent13.2.0 2,242 ms
Exact numbers
| PHPFUIBatch 3.0.3 | mariadb | 144 | 627 ms | 14.4 ms | 95.1 ms | 463 ms | 52.5 ms |
|---|---|---|---|---|---|---|---|
| Doctrine 3.6.2 | mariadb | 144 | 829 ms | 67.7 ms | 147 ms | 386 ms | 209 ms |
| Cycle 2.16.0 | mariadb | 144 | 936 ms | 228 ms | 70.2 ms | 374 ms | 257 ms |
| Atlas 2.0.1 | mariadb | 144 | 941 ms | 232 ms | 77.4 ms | 373 ms | 257 ms |
| PHPFUI 3.0.3 | mariadb | 144 | 1,050 ms | 238 ms | 92.4 ms | 451 ms | 266 ms |
| Propel2 6cb272b6 | mariadb | 144 | 1,091 ms | 282 ms | 15.2 ms | 428 ms | 361 ms |
| CakeCached 5.3.3 | mariadb | 144 | 1,168 ms | 263 ms | 198 ms | 568 ms | 134 ms |
| DivergenceV2 2.1.4 | mariadb | 144 | 1,170 ms | 269 ms | 111 ms | 520 ms | 267 ms |
| Cake 5.3.3 | mariadb | 144 | 1,187 ms | 271 ms | 202 ms | 575 ms | 133 ms |
| DivergenceV3 3.2.0 | mariadb | 144 | 1,307 ms | 280 ms | 154 ms | 598 ms | 273 ms |
| Yii 2.0.54 | mariadb | 144 | 1,336 ms | 268 ms | 135 ms | 563 ms | 366 ms |
| RedBean 5.7.5 | mariadb | 144 | 1,686 ms | 471 ms | 106 ms | 772 ms | 329 ms |
| Eloquent 13.2.0 | mariadb | 144 | 2,242 ms | 363 ms | 273 ms | 1,037 ms | 552 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.