From 905ef47363c109cb5381669ace6e208f45e1516d Mon Sep 17 00:00:00 2001 From: JSv4 Date: Thu, 28 May 2026 19:38:18 -0500 Subject: [PATCH] docs(changelog): cut v6.2.0 release notes MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Move the WorkerDocxodus.prepare() entry from [Unreleased] into a [6.2.0] section (released as tag v6.2.0) and correct the framing to the actual benefit — first-comparison warmup / JIT amortization, ~2x faster first compare — rather than network-fetch deferral, matching the final test in npm/tests/worker-prepare.spec.ts. --- CHANGELOG.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index c2cc7c3..f77c574 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -4,8 +4,10 @@ All notable changes to this project will be documented in this file. ## [Unreleased] +## [6.2.0] - 2026-05-28 + ### Added -- **`WorkerDocxodus.prepare()` — comparison-path warmup** (consumer issue JSv4/crowdsourced-redlines-js#2). `createWorkerDocxodus()` warms the .NET WASM runtime but does **not** load the comparison assemblies — the runtime defers `Docxodus.*.wasm` and its `System.*.wasm` dependents until the first real comparison, so the first `compareDocuments()` paid an extra ~3s of pure assembly-load latency. The new `prepare(): Promise` pays that cost up front: it runs a complete comparison inside the worker against two tiny seed documents constructed in-memory on the .NET side (no caller IO, no seed fixtures to ship), forcing every assembly the engine touches to resolve. After `await prepare()`, the next `compareDocuments()` / `compareDocumentsToHtml()` triggers no further `.wasm` fetches. The method is idempotent (repeated/concurrent calls share one in-flight warmup and resolve immediately once complete) and concurrent-safe (a `compareDocuments()` issued while a `prepare()` is in flight does not double-load assemblies). Implemented as a new `Warmup()` `[JSExport]` on `DocumentComparer`, a `"prepare"` worker message, and the `WorkerDocxodus.prepare()` proxy method. Tests: `npm/tests/worker-prepare.spec.ts` (verifies via page-level `.wasm` request monitoring that prepare loads `Docxodus.wasm`, the following compare loads none, idempotency resolves <50ms, and concurrent prepare+compare never double-loads). +- **`WorkerDocxodus.prepare()` — optional comparison-path warmup** (consumer issue JSv4/crowdsourced-redlines-js#2). `createWorkerDocxodus()` warms the .NET WASM runtime but does **not** exercise the comparison engine, so the first `compareDocuments()` pays a one-time warmup cost — comparison-assembly initialization plus JIT of the diff/XML stack — on top of the diff work (~2x the steady-state latency). Consumers worked around this by shipping seed `.docx` fixtures and running a throwaway compare for the side effect. The new optional `prepare(): Promise` pays the cost up front with no caller IO: it runs a complete comparison inside the worker against two tiny seed documents constructed in-memory on the .NET side (no seed fixtures to ship), forcing the full compare path to resolve and JIT. After `await prepare()`, the first real `compareDocuments()` / `compareDocumentsToHtml()` runs at steady-state speed and triggers no further `.wasm` fetches. `prepare()` is never called automatically — skip it and the first compare absorbs the warmup as before. It is idempotent (repeated/concurrent calls share one in-flight warmup and resolve immediately once complete) and concurrent-safe (a `compareDocuments()` issued while a `prepare()` is in flight does not double-load assemblies). Implemented as a new `Warmup()` `[JSExport]` on `DocumentComparer`, a `"prepare"` worker message, and the `WorkerDocxodus.prepare()` proxy method. Tests: `npm/tests/worker-prepare.spec.ts` verifies (via page-level `.wasm` request monitoring + in-worker timing) that after `prepare()` a real compare fetches no additional `.wasm`, a warmed first compare runs ~2x faster than a cold one (~758ms vs ~1504ms), a second `prepare()` resolves in <50ms, and concurrent prepare+compare never double-loads. ## [6.1.0] - 2026-05-28