@wcstack/state 1.21.6 → 1.21.7

package/README.ja.md

@@ -1832,6 +1832,47 @@ buildBindings(root)
 - **StateAddress** — PathInfo + ListIndex の組み合わせ
 - **AbsoluteStateAddress** — 状態名 + StateAddress（クロス状態参照用）
 
+## パフォーマンス
+
+リポジトリ同梱の [js-framework-benchmark](https://github.com/krausest/js-framework-benchmark) 流
+ドライバ（`e2e/bench/jsfb-verify.mjs`・`e2e/bench/memory-profile.mjs`）で、標準の
+1,000 / 10,000 行テーブルページを計測（headless Chromium・中央値・両実装を同一
+セッションで連続実行）。`@wcstack/state` は公式の keyed 判定に合格しつつ、行 DOM
+を上限 1,000 行の有界プールでリサイクルします。
+
+| 所要時間（ms・中央値） | `@wcstack/state` | [`@wcstack/signals`](../signals/) |
+|---|---|---|
+| 1,000 行の生成 | 25.2 | 9.5 |
+| 1,000 行の全置換 | 18.8 | 12.5 |
+| 10,000 行の 10 行ごと更新 | 11.4 | 4.7 |
+| 行の選択 | 0.1 | 0.4 |
+| 2 行の入れ替え | 0.9 | 0.4 |
+| 行の削除 | 2.8 | 0.6 |
+| 10,000 行への 1,000 行追加 | 48.6 | 14.2 |
+| 10,000 行のクリア | 54.6 | 52.2 |
+
+| 強制 GC 後のヒープ（MB） | `@wcstack/state` | `@wcstack/signals` |
+|---|---|---|
+| ページ表示直後 | 1.0 | 0.6 |
+| 1,000 行生成後 | 5.6 | 3.5 |
+| 1,000 行×5 回置換後 | 6.4 | 3.7 |
+| 10,000 行生成後 | 35.1 | 18.0 |
+| 10,000 行生成 + クリア後 | 13.2 | 1.9 |
+
+正直な読み方：
+
+- 対話系の操作（選択 / 入れ替え / 削除）は数ミリ秒以下で、巨大リストのクリアは
+  signals 実装と同等です。
+- 行の生成・追加は `@wcstack/signals` の約 2.5〜3.5 倍のコストです。これは本
+  パッケージが行ごとに構築する宣言的バインディング台帳の対価で、`data-wcs` の
+  検査・DevTools の配線表示・SSR ハイドレーションを支えているのは同じ台帳です。
+  両パッケージは相互運用できるため、ホットなリストだけ signals の `For` で描画
+  し、残りのページは宣言的なまま保てます。
+- クリア後に残るヒープは、次のリスト生成を安くする有界の行プールです。
+
+絶対値は 1 台の開発機での計測です（v1.21.6 + PR#87 の clear リーク修正）。
+`e2e/bench/` のドライバで手元のハードウェアでも再現できます。
+
 ## サーバーサイドレンダリング
 
 `@wcstack/state` は [`@wcstack/server`](../server/) パッケージと連携して SSR をサポートしています。クライアント用に書いたテンプレートがそのままサーバーでレンダリングされます — 変更不要。

package/README.md

@@ -1834,6 +1834,50 @@ Paths like `users.*.name` are decomposed into:
 - **StateAddress** — combination of PathInfo + ListIndex
 - **AbsoluteStateAddress** — state name + StateAddress (for cross-state references)
 
+## Performance
+
+Measured with the repository's [js-framework-benchmark](https://github.com/krausest/js-framework-benchmark)-style
+drivers (`e2e/bench/jsfb-verify.mjs`, `e2e/bench/memory-profile.mjs`) against the
+standard 1,000 / 10,000-row table page — headless Chromium, medians, both
+implementations measured back-to-back in the same session. `@wcstack/state`
+passes the official keyed-mode classification while recycling row DOM through a
+bounded pool (up to 1,000 rows).
+
+| Duration (ms, median) | `@wcstack/state` | [`@wcstack/signals`](../signals/) |
+|---|---|---|
+| create 1,000 rows | 25.2 | 9.5 |
+| replace all 1,000 rows | 18.8 | 12.5 |
+| update every 10th of 10,000 | 11.4 | 4.7 |
+| select row | 0.1 | 0.4 |
+| swap 2 rows | 0.9 | 0.4 |
+| remove row | 2.8 | 0.6 |
+| append 1,000 to 10,000 | 48.6 | 14.2 |
+| clear 10,000 rows | 54.6 | 52.2 |
+
+| Heap after forced GC (MB) | `@wcstack/state` | `@wcstack/signals` |
+|---|---|---|
+| page ready | 1.0 | 0.6 |
+| after create 1,000 | 5.6 | 3.5 |
+| after 5× replace 1,000 | 6.4 | 3.7 |
+| after create 10,000 | 35.1 | 18.0 |
+| after create 10,000 + clear | 13.2 | 1.9 |
+
+How to read this, honestly:
+
+- Interactive operations (select / swap / remove) run in a few milliseconds or
+  less, and clearing a huge list matches the signals implementation.
+- Creating and appending rows costs ~2.5–3.5× `@wcstack/signals`. That is the
+  price of the declarative binding ledger this package builds per row — the same
+  ledger that powers `data-wcs` inspection, DevTools wiring, and SSR hydration.
+  The two packages interoperate, so a hot list can be rendered with signals'
+  `For` while the rest of the page stays declarative.
+- The heap retained after a clear is the bounded row pool that makes the next
+  list population cheap.
+
+Absolute numbers are from one development machine (v1.21.6 + the clear-leak fix
+in PR#87); the drivers in `e2e/bench/` reproduce the comparison on your own
+hardware.
+
 ## Server-Side Rendering
 
 `@wcstack/state` supports SSR via the companion [`@wcstack/server`](../server/) package. The same templates you write for the client render on the server — no changes needed.

package/dist/index.esm.js

@@ -3849,13 +3849,22 @@ class BindingSession {
     }
     /**
      * 全 record を teardown を走らせずに終端化する（canWholesaleDestroy が true の
-     * content 専用）。イベント listener・アドレス台帳・loopContext はノード/binding
-     * もろとも GC で崩壊する（recordByBinding 以下は全て弱参照）。
+     * content 専用）。イベント listener・loopContext・パターン台帳（listIndex キー）は
+     * ノード/binding もろとも GC で崩壊する（recordByBinding 以下は全て弱参照）。
+     * 例外は null-listIndex の従来台帳（record.address）: キーの intern 済み
+     * AbsoluteStateAddress が PathInfo キャッシュ経由で生涯生存するため GC で
+     * 崩壊せず、共有エントリに残った binding が binding.node 経由で行 DOM 全体を
+     * 永久リークする。ここだけ明示除去する（行イベント binding が典型で行あたり
+     * 高々数件・Set.delete のみなので wholesale の速度特性は保たれる）。
      * handlerBindingRegistry のカウンタは減らないが、残るのはキー文字列と数値のみで
      * 実害はない設計（handlerBindingRegistry.ts の弱参照化コメント参照）。
      */
     destroyRecords() {
         for (const record of this.records) {
+            if (record.address !== null) {
+                removeBindingByAbsoluteStateAddress(record.address, record.info);
+                record.address = null;
+            }
             record.phase = "disposed";
             record.teardowns = null;
         }
@@ -6864,7 +6873,7 @@ async function buildBindings(root) {
     }
 }
 
-var version = "1.21.6";
+var version = "1.21.7";
 var pkg = {
 	version: version};