IntersectMBO / IntersectMBO/evolution-sdk

[Tangent] Eliminate duplicate WithLength decoder family in CBOR.ts

オープン
#159 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る
exploration
主要言語
TypeScript
スター
22
フォーク
30
平均マージ
5時間 29分
マージ済み PR(30日)
12

説明

## What was discovered
CBOR.ts has two complete decoder implementations side-by-side: an offset-based family (\`decodeItemAt\`, \`decodeBytesAt\`, \`decodeArrayAt\`, …) and a slice-based family (\`decodeItemWithLengthSync\`, \`decodeBytesWithLengthSync\`, \`decodeArrayWithLengthSync\`, …). The slice-based family calls \`data.slice(offset)\` at every recursion, allocating a new \`Uint8Array\` for each nested item.

## Surfaced during
CBOR module review while preparing the \`bounded_bytes\` / \`BoundedBytes\` fix (PR for Conway CDDL compliance). Found during full read of CBOR.ts decoder section (~lines 1600–1900).

## Why it's worth exploring
For deeply nested PlutusData (constr with 5 levels, many fields), the slice-based path allocates hundreds of \`Uint8Array\` copies. The offset-based family is strictly better — it threads an integer offset through the call chain with zero allocation overhead. The two families are functionally equivalent. Deleting the \`WithLength\` family and routing its callers to the offset-based one removes ~200 lines and eliminates the O(n²) allocation pattern.

## What would be needed
1. Identify all callers of the \`WithLength\` family inside CBOR.ts
2. Route them to the offset-based equivalents (\`decodeItemAt\` etc.)
3. Delete the \`WithLength\` family
4. Run the full CBOR test suite (968 tests) to confirm no regression
5. Benchmark with a deeply nested PlutusData value to quantify the win (optional but useful)

## Context snapshot
Relevant section: \`packages/evolution/src/CBOR.ts\` ~lines 1600–1900.

The slice-based family:
\`\`\`typescript
const decodeItemWithLengthSync = (data: Uint8Array, options: CodecOptions): { item: CBOR; bytesConsumed: number } => {
// ... dispatches to decodeBytesWithLengthSync, decodeArrayWithLengthSync, etc.
// Each calls data.slice(offset) before recursing — one allocation per node
}
\`\`\`

The offset-based family (keeper):
\`\`\`typescript
const decodeItemAt = (data: Uint8Array, offset: number, options: CodecOptions): DecodeAtResult => {
// ... threads offset integer — zero allocation
}
\`\`\`
Both produce identical decoded values. The \`WithLength\` family exists as a legacy parallel path and has no unique capabilities the offset family lacks.

コントリビューションガイド

コントリビューションガイドを開く

調査の方向性

packages/evolution/src/CBOR.ts の 1600–1900 行付近から始め、decodeItemWithLengthSync と関連する WithLength 関数のすべての呼び出し元を特定します。それらの呼び出し元を、オフセットベースの decodeItemAt ファミリーと比較し、その後 CBOR の全テストスイート(968 テスト)を実行します。WithLength レガシーファミリーが削除され、呼び出し元がオフセットベースのパスを使用し、テストスイートでリグレッションが発生しないことが完了の条件です。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
typescript
領域
backend
issue の種類
リファクタリング
難易度
4/5
見積もり時間
3〜5日
活発さ
静か
明瞭さ
おおむね明確
初心者へのやさしさ
45/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。