docs: label the h5repack sizes in the append-waste figures

306 104 and 49 930 are h5repack of the editor's file; the text read as if
they were h5repack of libhdf5's, which measures 305 954 and 50 188. Both
are now given, from measure_append_waste rerun on 2026-09-26 (file sizes
unchanged).

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
This commit is contained in:
osobh
2026-09-26 18:50:23 -05:00
co-authored by Claude Opus 5.5
parent a69c5be8b2
commit c2ae7846c9
+6 -4
View File
@@ -98,10 +98,12 @@ Measured 2026-09-26 on tank with `cargo test -p clawhdf5-tools --test
edit_interop -- --ignored --nocapture measure_append_waste` (one editor for
the whole workload; file sizes are deterministic): 1000 appends of 100 `f8`
values to a 1-D dataset with 1024-element chunks give 810 504 bytes
unfiltered, as libhdf5's file, and 306 780 bytes with gzip (307 210 before
reuse; libhdf5: 306 058; `h5repack`: 306 104); 2000 appends of 10 values
with 4096-element gzip chunks give 79 829 bytes (119 684 before reuse)
against libhdf5's 50 292 (`h5repack`: 49 930): the chunk being appended to
unfiltered, as libhdf5's file (`h5repack` of either: 810 360), and 306 780
bytes with gzip (307 210 before reuse; libhdf5's file: 306 058; `h5repack`
of the editor's file: 306 104, of libhdf5's: 305 954); 2000 appends of 10
values with 4096-element gzip chunks give 79 829 bytes (119 684 before
reuse) against libhdf5's 50 292 (`h5repack` of the editor's file: 49 930,
of libhdf5's: 50 188): the chunk being appended to
is followed by new index blocks and moves each time it grows, and the
space it leaves is too small for its next, larger version.