# Phase 1 gate — mongo-lite vs MongoDB 8.3.7, 1g dataset / ~16k docs
# ratio < 1.0 = mongo-lite faster. Reproduce: bash tests/e2e/compare-run.sh 1g 16k
# Run-to-run noise is roughly +/-15% on the scan rows; mongod's own numbers
# moved that much across the runs below.

benchmark                                   mongo-lite              mongodb                 ratio
insertOne (sequential) x200                 0.19 ms                 5.0 ms                  0.0x
bulk insert throughput                      852.9 MB/s              689.6 MB/s              1.2x
docs loaded                                 65,536                  65,536                  1.0x
createIndex({k: 1})                         62.4 ms                 78.4 ms                 0.8x
countDocuments({})                          1.5 ms                  11.5 ms                 0.1x
findOne({_id: <ObjectId>})                  0.48 ms                 0.54 ms                 0.9x
findOne({k: 500}) (indexed)                 0.64 ms                 4.3 ms                  0.1x
find({p: {$gte,$lt}}).count() (scan)        21.4 ms                 12.7 ms                 1.7x
find({}).sort({_id:-1}).limit(20)           7.1 ms                  2.0 ms                  3.5x
find({}, {proj}).limit(1000)                3.7 ms                  4.3 ms                  0.9x
aggregate $group by k                       9.8 ms                  13.7 ms                 0.7x
updateOne({_id}) x50                        0.16 ms                 0.19 ms                 0.8x
updateMany({k: 7}, {$inc})                  17.3 ms                 6.1 ms                  2.8x
deleteOne({_id}) + insertOne                0.62 ms                 4.9 ms                  0.1x
node client RSS                             160 MB                  164 MB                  1.0x
server RSS                                  1974 MB                 1386 MB
kill -9 reopen                              0.8s                    1.3s
db on disk                                  1025MB                  93MB

# Baseline before Phase 1:
#   bulk insert 267 MB/s | createIndex 0.66s | sort+limit 40ms | countDocuments 2.5ms
#   range-scan 25ms | updateMany 20ms | reopen 3.8s | disk 1.0GB | RSS 2.0GB
#
# Remaining gaps and where they are addressed:
#   db on disk   11x  -> Phase 3 (block-compressed log)
#   sort+limit  3.5x  -> Phase 2 (index-ordered scan, _id as an ordered index)
#   updateMany  2.8x  -> Phase 2 (B+tree; remove_id is a linear scan per index)
#   range-scan  1.7x  -> Phase 4, not the matcher. The stack-buffer change
#                        measured 15.7 -> 12.0ms in isolation, but this row is
#                        bound by walking 65,536 documents that each live in
#                        their own arena: hash-map iteration plus a pointer
#                        chase per document. Contiguous byte storage is the fix.
#   server RSS  1.4x  -> Phase 4 (per-document arena -> byte storage)