perf(investigate): svs → cog-wsi verbatim tile-copy ~10x slower than tiff/ome-tiff for identical output (IFD spooling path?)

[cornish]

Type

Perf / investigation (not a confirmed defect) — may well be inherent to the COG-WSI layout; filing so the cost is measured and the spool path is looked at deliberately.

Observation

A no-transform, no-codec-change convert (verbatim tile-copy) from SVS to cog-wsi runs ~10× slower than the same tile-copy to tiff/ome-tiff, for byte-identical output size. Controlled, back-to-back, -q, same source (CMU-2.svs, 78000×30462, jpeg tiles):

svs -> ome-tiff   1.08s / 0.94s     out 402,743,571
svs -> tiff       0.94s / 0.97s     out 402,740,907
svs -> cog-wsi    9.95s / 9.90s     out 402,717,328

Reproducible and stable when isolated (run-to-run variance in a full batch was just concurrency). Output size ≈ the jpeg copies, so tiles are not being re-encoded to htj2k — the same compressed bytes are written, but the cog-wsi writer spends ~9s of extra wall-clock the plain-TIFF / OME-TIFF writers don't.

Repro:

wsitools convert --to tiff     -q -f -o out.tiff     CMU-2.svs   # ~1s
wsitools convert --to ome-tiff -q -f -o out.ome.tiff CMU-2.svs   # ~1s
wsitools convert --to cog-wsi  -q -f -o out.cog.tiff CMU-2.svs   # ~10s

Probable cause

COG-WSI writes its IFDs up front (offsets must precede the tile data for a cloud-optimized layout), so later IFDs have to be spooled to generate the pointers — an extra pass / buffering that the append-as-you-go plain-TIFF and OME-TIFF writers avoid. So some overhead is expected by construction.

Question for the investigation

Is the ~10× (≈9s of added wall-clock on a ~400 MB verbatim copy) proportionate to the unavoidable spooling, or is there avoidable per-tile overhead in the spool path — e.g. an extra decode/copy pass, per-tile allocation, unbuffered spool I/O, or work that could be single-pass with offset back-patching? A quick profile of the cogwsi write path on this input would settle whether ~10× is the floor or has headroom.

Likely related: #3 (deterministic write mode for cogwsiwriter).

Environment

wsitools 0.26.3, Windows (MSYS2/MinGW). Numbers above are from tile-copy (no --codec, no transform).

[cornish]

Investigation results

Verdict: the ~10× is NOT all inherent spooling — there was real avoidable overhead. Two bugs in the spool-and-finalize path, plus a genuinely-inherent remainder.

Confirmed on macOS (CMU-2, warm cache, verbatim tile-copy, 3 runs)

target	before	after fixes
tiff	0.18s	0.18s
ome-tiff	0.19s	—
cog-wsi	0.53s	0.34s

So even on macOS cog-wsi was ~3× (not the 10× seen on Windows — the per-tile syscalls below are cheap on macOS, which is why Windows amplifies it). Output is byte-identical before/after (same SHA) — pure perf change.

Root causes

1. O(n²) offset computation (fixed). spool.ReadEntryAt(idx) re-summed the lengths of all preceding entries to find each tile's byte offset. The finalize read-back calls it once per tile, so the total is ~n²/2 — for CMU-2's ~36k L0 tiles that's hundreds of millions of iterations of pure CPU. Now each entry stores its offset at Append time → O(1) lookup. (This is CPU, so it costs the same absolute on Windows.)

2. Unbuffered per-tile spool writes (fixed). Append did os.File.Write per tile — one syscall per tile (~36k). Now buffered (1 MiB), flushed lazily before read-back. This is the bigger Windows win — per-tile write syscalls are ~10× costlier on Windows/MinGW than macOS.

The remaining cost (inherent-ish; the bulk of the Windows 10×)

The finalize read-back still does, per tile: one ReadAt (spool) + one WriteAt (output) = ~72k syscalls for CMU-2. On Windows that's the dominant term. It looks streamable for the default row-major order (spool order == emission order), but the output is not contiguous: layout.go aligns each tile to a 16-byte boundary (alignUp(cursor, tileAlign)), while the spool packs tiles tightly. So a bulk io.Copy would not reproduce the padding — the per-tile WriteAt at aligned offsets is load-bearing.

Closing this needs a padding-aware refactor: read the spool sequentially through a buffered reader (kills the per-tile ReadAt) and coalesce output through a buffered offset-writer that emits the 16-byte gaps (kills the per-tile WriteAt). Byte-identity is verifiable, but it touches the correctness-critical finalize path and its Windows benefit can only be measured on Windows.

Shipped (this issue)

The two fixes above — O(1) offsets + buffered spool — byte-identical, full cog-wsi suite + integration green. macOS 0.53s → 0.34s. Related to #3 (deterministic cogwsiwriter). The read-back streaming is left as a follow-up.