Sized by the CPU cap, not by the record cap, and the correction is measured.
The old default was 2,000,000 -- chosen because it fits DO_SQLITE_MAX_RECORD_BYTES -- and a
deployed sweep with HEAP_RESTORE_CHUNKS=1 showed the record cap is not the binding constraint:
chunk bytes
rows
per-firing edge cpuTime
over the 10 ms cap
2,000,000
5
median 29, max 52 ms
3 of 4
400,000
21
median 8, max 13 ms
4 of 21
200,000
41
median 2, max 10 ms
0 of 41
So the goal of chunking -- one restore step inside one free-plan invocation -- only holds
at roughly this size. 41 rows for an 8.1 MB elided image is still a handful of reads, and rows are
not the meter that binds. The cost is not the memcpy: each chunk is also digested by a per-byte
JS loop (digestBytes), so per-firing CPU tracks chunk size closely.
Default bytes per stored chunk.
Sized by the CPU cap, not by the record cap, and the correction is measured. The old default was 2,000,000 -- chosen because it fits
DO_SQLITE_MAX_RECORD_BYTES-- and a deployed sweep withHEAP_RESTORE_CHUNKS=1showed the record cap is not the binding constraint:So the goal of chunking -- one restore step inside one free-plan invocation -- only holds at roughly this size. 41 rows for an 8.1 MB elided image is still a handful of reads, and rows are not the meter that binds. The cost is not the memcpy: each chunk is also digested by a per-byte JS loop (
digestBytes), so per-firing CPU tracks chunk size closely.