hakmem/docs/analysis/PHASE12_STRATEGIC_OPTIONS_ANALYSIS.md

Phase 12: Strategic Options Analysis（次の方向性）

Date: 2025-12-14 Status: 📊 STRATEGIC DECISION POINT Context: Phase 6-10 で +24.6% 達成、Phase 11 NO-GO (-8.35%)

---

Executive Summary

Phase 6-10 で +24.6% の累積改善を達成し、大きな構造最適化（consolidation, deduplication）は完了しました。Phase 11 (ENV snapshot maybe-fast) は設計ミスで NO-GO、Alloc 側の深掘りも FastLane 実装済みで構造改善の余地が枯渇しています。

次の Phase は Micro-optimization 領域（各 +1-2% ROI）に移行しており、リスク/リワード比が低下しています。

推奨: Strategic Pause（戦略的休止）— プロジェクト目標を再評価し、次の大きな方向性を決定するタイミング

---

現状分析

Phase 6-10 の成果

Metric	Before	After	Improvement
Throughput (Mixed)	43.04M ops/s	53.62M ops/s	+24.6% 🎉
累積改善（Phase 5-10）	Baseline	~+30-35%	Major milestone

Key Phases:

• Phase 6-1 (FastLane): +11.13%（hakmem 史上最大）
• Phase 6-2 (Free DeDup): +5.18%
• Phase 8 (ENV Cache Fix): +2.61%
• Phase 9 (MONO DUALHOT): +2.72%
• Phase 10 (MONO LEGACY DIRECT): +1.89%

確立された技術パターン

Winning Patterns ✅:

1. Wrapper-level consolidation（層の集約）— Phase 6-1: +11.13%
2. Deduplication（重複削減）— Phase 6-2: +5.18%
3. Monolithic early-exit（関数 split より有効）— Phase 9, 10
4. ENV gate synchronization（最適化を確実に効かせる）— Phase 8

Anti-Patterns ❌:

1. Function split for lightweight paths — Phase 7: -2.16%
2. Call-site API changes — Phase 11: -8.35%

---

Phase 11 の失敗と Alloc 調査結果

Phase 11: ENV Snapshot "maybe-fast" API — ❌ NO-GO (-8.35%)

狙い: hakmem_env_snapshot* / tiny_front_v3_snapshot_get の固定費削減（~2-3%）

結果: 51.65M → 47.33M ops/s（-8.35%）

根本原因:

• maybe_fast() を inline hot path 関数内で呼んだことで、ctor_mode check が累積
• Compiler optimization 阻害
• Even 2-3 instructions are expensive at high call frequency

教訓: ENV gate 最適化は gate 自体を改善すべきで、call site を変更すると逆効果

Alloc Side Deep Dive — 構造改善の余地なし

調査結果:

• Alloc 側も Phase 6 で FastLane 実装済み
• front_fastlane_try_malloc で size→class→handler を集約済み
• 重複チェックも既に削減（Phase 6-2 パターン適用済み）

結論: Alloc 側の大きな構造改善の余地は 枯渇

---

Perf Profile（Phase 10 後）

Hotspot 分析

Symbol	Self%	分類	最適化余地
front_fastlane_try_free	33.88%	集約点（期待通り）	✅ 最適化完了
main	26.21%	Benchmark overhead	N/A（最適化不可）
malloc	21.43%	Alloc wrapper 集約点	✅ FastLane 実装済み
tiny_header_finalize_alloc	5.33%	Header write	⚪ E5-2 NEUTRAL（再最適化困難）
tiny_c7_ultra_alloc	3.75%	C7 ULTRA path	🔍 C7 専用（狭いスコープ）
unified_cache_push	1.61%	Cache push	🔍 Marginal ROI (~+1.0%)
hakmem_env_snapshot	0.82%	ENV snapshot	❌ Phase 11 NO-GO
tiny_front_v3_snapshot_get	0.66%	Front snapshot	❌ Phase 11 NO-GO

Key Observations

1. Top 3 hotspots (80%+) = 集約点

   • FastLane free (33.88%) + malloc (21.43%) + main (26.21%) = 81.52%
   • これらは「consolidation が成功した証拠」であり、bottleneck ではない

2. Remaining hotspots < 4%

   • 各最適化の ROI は +1-2% 程度（marginal）
   • リスク/リワード比が低下

3. 大きな構造改善の機会 = なし

   • Consolidation, deduplication は既に適用済み
   • 次のブレークスルーが見つからない状況

---

Phase 12 の選択肢

Option A: Micro-Optimization（継続）⚪ LOW PRIORITY

Target 候補:

1) tiny_c7_ultra_alloc (3.75%) — C7 ULTRA 最適化

Scope: C7 (1025-2048B) 専用の alloc path

Expected ROI: +1-2%（Mixed 全体では marginal、C7-heavy では +3-5%？）

Risk:

• C7 専用のため Mixed 全体への影響は限定的
• 既に Phase 4-4 などで最適化済みの可能性

Recommendation: ⚪ NEUTRAL — C7-heavy workload に特化するなら検討

---

2) unified_cache_push (1.61%) — Cache push 最適化

Scope: Unified cache への push 操作

Expected ROI: ~+1.0%（Phase 5 E5-3b で予測済み）

Risk:

• 既に最適化されている可能性
• Branch overhead ≈ savings（E5-2 の教訓）

Recommendation: ⚪ NEUTRAL — 予想 ROI が低い（+1.0%）

---

3) その他の micro-opt

• tiny_header_finalize_alloc (5.33%): E5-2 で NEUTRAL（+0.45%）、再最適化困難
• hakmem_env_snapshot (0.82%): Phase 11 で NO-GO、別アプローチ要検討

Overall Assessment for Option A:

• ✅ 可能（実装可能）
• ⚠️ Marginal ROI（各 +1-2%）
• ⚠️ High Risk（NO-GO 確率 20-30%）
• ⚠️ Diminishing Returns（リスク >> リワード）

---

Option B: Workload-Specific Optimization（特化最適化）🔍 MEDIUM PRIORITY

Strategy: Mixed workload ではなく、特定のワークロードに特化した最適化

B-1: C6-heavy Optimization（257-768B 特化）

Background:

• C6-heavy workload では MID v3 / MID v3.5 が有効（既に Phase v11a で実証）
• Mixed では LEGACY が最速だが、C6-heavy では MID v3.5 が +8% 改善

Next Steps:

• C6-heavy 専用プロファイルの作成・最適化
• C6 range での micro-opt（tiny_c7_ultra_alloc の C6 版など）

Expected ROI: C6-heavy で +3-5%（Mixed では変化なし）

Trade-off: Mixed vs C6-heavy の最適化が conflict する可能性

---

B-2: Large Allocation Optimization（> 1KB）

Background:

• 現在の最適化は Tiny (16-1024B) に集中
• Mid/Large (> 1KB) の最適化は未着手

Next Steps:

• Mid/Large allocator の perf profile
• Pool v2, Shared SuperSlab などの最適化

Expected ROI: 不明（要調査）

Risk: Mixed workload（16-1024B 中心）では効果が限定的

---

Overall Assessment for Option B:

• ✅ 新しいフロンティア（Tiny 以外の領域）
• ⚠️ Workload-dependent（Mixed では効果限定的）
• 🔍 要調査（ROI が不明確）

---

Option C: Strategic Pause（戦略的休止）✅ RECOMMENDED

Rationale:

1. Major Milestone Achieved: +24.6% (Phase 6-10) + +10% (Phase 5) = **+30-35% 累積**

   • hakmem 史上最大の改善を達成
   • 大きな構造最適化は完了

2. Diminishing Returns: 残り最適化は marginal ROI（< +2% 各）

   • 各 Phase の NO-GO リスク: 20-30%
   • リスク/リワード比が低下

3. Need for Strategic Reboot: 次のブレークスルーが見えない状況

   • Consolidation, deduplication は適用済み
   • 新しい最適化パターンが必要

4. Time for Reflection: プロジェクト目標を再評価するタイミング

   • 現在の性能は目標に対してどこまで到達？
   • mimalloc 比較、production workload 検証など

Next Actions（Pause 期間）:

1. ベンチマーク比較:

   • mimalloc, jemalloc, tcmalloc との比較
   • Production workload でのテスト

2. Code Quality:

   • Tech debt の整理
   • Documentation の充実

3. Next Frontier 探索:

   • Memory footprint 削減
   • Multi-thread scalability
   • Fragmentation 改善

4. プロジェクト目標の再設定:

   • 性能目標の明確化（e.g., "mimalloc の 95%" など）
   • 次の major optimization の方向性

Overall Assessment for Option C:

• ✅ 最も合理的な選択
• ✅ Major milestone で一旦休止
• ✅ 次の戦略を練る時間を確保
• ✅ リスクなし（何もしないことで性能劣化はない）

---

判定基準（Decision Matrix）

Option	Expected ROI	Risk (NO-GO)	Effort	Strategic Value	推奨度
A: Micro-Opt	+1-2% per phase	20-30%	Medium	LOW（漸進的）	⚪ NEUTRAL
B: Workload-Specific	+3-5% (specific)	10-20%	High	MEDIUM（新領域）	🔍 DEFER
C: Strategic Pause	0%	0%	Low	HIGH（戦略再構築）	✅ RECOMMENDED

---

Recommendation

Primary: Option C（Strategic Pause）

理由:

1. Phase 6-10 で +24.6% を達成（大きなマイルストーン）
2. 残り最適化は marginal ROI（リスク >> リワード）
3. 次のブレークスルーが見えない状況（新しい戦略が必要）

Pause 期間にやるべきこと:

• mimalloc/jemalloc との比較ベンチマーク
• Production workload 検証
• Tech debt 整理、documentation 充実
• Next frontier 探索（memory footprint, multi-thread, fragmentation）

---

Alternative: Option A（Micro-Opt）（ユーザーが継続を希望する場合）

推奨順:

1. tiny_c7_ultra_alloc (3.75%) — C7-heavy で +2-3% の可能性
2. unified_cache_push (1.61%) — Mixed で +1.0% の可能性

注意:

• 各 Phase の NO-GO リスク: 20-30%
• ROI が低く、コスト/ベネフィットが悪化
• Phase 11 の失敗を踏まえ、慎重に設計

---

結論

Phase 6-10 で hakmem は +24.6% の大幅な性能改善を達成し、大きな構造最適化は完了しました。

次の Phase は:

• Micro-optimization 領域（各 +1-2% ROI、リスク高）
• または Strategic Pause（戦略再構築）

のいずれかです。

推奨: Strategic Pause — プロジェクト目標を再評価し、次の大きな方向性を決定するタイミング。

---

Analysis: Claude Code Date: 2025-12-14 Context: Phase 6-10 累積 +24.6%、Phase 11 NO-GO (-8.35%)、Alloc 側も最適化済み