m10-performance
パフォーマンス改善に特化し、最適化、ベンチマーク、プロファイリングなどのキーワードに反応して、処理速度向上やメモリ効率化など、システムをより高速化するための提案を行うSkill。
📜 元の英語説明(参考)
CRITICAL: Use for performance optimization. Triggers: performance, optimization, benchmark, profiling, flamegraph, criterion, slow, fast, allocation, cache, SIMD, make it faster, 性能优化, 基准测试
🇯🇵 日本人クリエイター向け解説
パフォーマンス改善に特化し、最適化、ベンチマーク、プロファイリングなどのキーワードに反応して、処理速度向上やメモリ効率化など、システムをより高速化するための提案を行うSkill。
※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。
下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o m10-performance.zip https://jpskill.com/download/9268.zip && unzip -o m10-performance.zip && rm m10-performance.zip
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/9268.zip -OutFile "$d\m10-performance.zip"; Expand-Archive "$d\m10-performance.zip" -DestinationPath $d -Force; ri "$d\m10-performance.zip"
完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。
💾 手動でダウンロードしたい(コマンドが難しい人向け)
- 1. 下の青いボタンを押して
m10-performance.zipをダウンロード - 2. ZIPファイルをダブルクリックで解凍 →
m10-performanceフォルダができる - 3. そのフォルダを
C:\Users\あなたの名前\.claude\skills\(Win)または~/.claude/skills/(Mac)へ移動 - 4. Claude Code を再起動
⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。
🎯 このSkillでできること
下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。
📦 インストール方法 (3ステップ)
- 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
- 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
- 3. 展開してできたフォルダを、ホームフォルダの
.claude/skills/に置く- · macOS / Linux:
~/.claude/skills/ - · Windows:
%USERPROFILE%\.claude\skills\
- · macOS / Linux:
Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。
詳しい使い方ガイドを見る →- 最終更新
- 2026-05-18
- 取得日時
- 2026-05-18
- 同梱ファイル
- 1
📖 Skill本文(日本語訳)
※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。
パフォーマンス最適化
レイヤー 2: 設計の選択
中核となる問い
ボトルネックは何か、そして最適化は価値があるか?
最適化する前に:
- 測定しましたか? (推測しない)
- 許容できるパフォーマンスは?
- 最適化は複雑さを増しますか?
パフォーマンスの決定 → 実装
| ゴール | 設計の選択 | 実装 |
|---|---|---|
| アロケーションの削減 | 事前割り当て、再利用 | with_capacity、オブジェクトプール |
| キャッシュの改善 | 連続したデータ | Vec、SmallVec |
| 並列化 | データ並列性 | rayon、スレッド |
| コピーの回避 | ゼロコピー | 参照、Cow<T> |
| 間接参照の削減 | インラインデータ | smallvec、配列 |
思考のプロンプト
最適化する前に:
-
測定しましたか?
- まずプロファイル → flamegraph, perf
- ベンチマーク → criterion, cargo bench
- 実際のホットスポットを特定
-
優先順位は何ですか?
- アルゴリズム (10倍-1000倍の改善)
- データ構造 (2倍-10倍)
- アロケーション (2倍-5倍)
- キャッシュ (1.5倍-3倍)
-
トレードオフは何ですか?
- 複雑さ vs 速度
- メモリ vs CPU
- レイテンシ vs スループット
上流へのトレース ↑
ドメイン制約へ (レイヤー 3):
"これはどれくらい速くする必要があるか?"
↑ 質問: パフォーマンス SLA は何ですか?
↑ 確認: domain-* (レイテンシ要件)
↑ 確認: ビジネス要件 (許容できる応答時間)
| 質問 | トレース先 | 質問 |
|---|---|---|
| レイテンシ要件 | domain-* | 許容できる応答時間は? |
| スループットのニーズ | domain-* | 1秒あたりのリクエスト数は? |
| メモリ制約 | domain-* | メモリ予算は? |
下流へのトレース ↓
実装へ (レイヤー 1):
"アロケーションを削減する必要がある"
↓ m01-ownership: 参照を使用し、clone を避ける
↓ m02-resource: with_capacity で事前割り当て
"並列化する必要がある"
↓ m07-concurrency: rayon またはスレッドを選択
↓ m07-concurrency: I/O バウンドの場合は async を検討
"キャッシュ効率が必要"
↓ データレイアウト: 可能な場合は HashMap よりも Vec を優先
↓ アクセスパターン: ランダムアクセスよりもシーケンシャルアクセス
クイックリファレンス
| ツール | 目的 |
|---|---|
cargo bench |
マイクロベンチマーク |
criterion |
統計的ベンチマーク |
perf / flamegraph |
CPU プロファイリング |
heaptrack |
アロケーション追跡 |
valgrind / cachegrind |
キャッシュ分析 |
最適化の優先順位
1. アルゴリズムの選択 (10倍 - 1000倍)
2. データ構造 (2倍 - 10倍)
3. アロケーション削減 (2倍 - 5倍)
4. キャッシュ最適化 (1.5倍 - 3倍)
5. SIMD/並列処理 (2倍 - 8倍)
一般的なテクニック
| テクニック | いつ | 方法 |
|---|---|---|
| 事前割り当て | サイズが既知 | Vec::with_capacity(n) |
| クローンを避ける | ホットパス | 参照または Cow<T> を使用 |
| バッチ処理 | 多数の小さな操作 | 収集してから処理 |
| SmallVec | 通常は小さい | smallvec::SmallVec<[T; N]> |
| インラインバッファ | 固定サイズのデータ | Vec よりも配列 |
よくある間違い
| 間違い | なぜ間違っているか | より良い方法 |
|---|---|---|
| プロファイリングなしで最適化 | 誤ったターゲット | まずプロファイル |
| デバッグモードでベンチマーク | 無意味 | 常に --release |
| LinkedList を使用 | キャッシュフレンドリーでない | Vec または VecDeque |
隠れた .clone() |
不要なアロケーション | 参照を使用 |
| 早すぎる最適化 | 無駄な努力 | まず動作させる |
アンチパターン
| アンチパターン | なぜ悪いか | より良い方法 |
|---|---|---|
| ライフタイムを避けるためにクローン | パフォーマンスコスト | 適切な所有権 |
| すべてを Box 化 | 間接参照コスト | 可能な場合はスタック |
| 小さなセットに HashMap | オーバーヘッド | 線形探索で Vec |
| ループ内の String 連結 | O(n^2) | String::with_capacity または format! |
関連スキル
| いつ | 参照 |
|---|---|
| クローンを減らす | m01-ownership |
| 並行処理のオプション | m07-concurrency |
| スマートポインタの選択 | m02-resource |
| ドメイン要件 | domain-* |
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開
Performance Optimization
Layer 2: Design Choices
Core Question
What's the bottleneck, and is optimization worth it?
Before optimizing:
- Have you measured? (Don't guess)
- What's the acceptable performance?
- Will optimization add complexity?
Performance Decision → Implementation
| Goal | Design Choice | Implementation |
|---|---|---|
| Reduce allocations | Pre-allocate, reuse | with_capacity, object pools |
| Improve cache | Contiguous data | Vec, SmallVec |
| Parallelize | Data parallelism | rayon, threads |
| Avoid copies | Zero-copy | References, Cow<T> |
| Reduce indirection | Inline data | smallvec, arrays |
Thinking Prompt
Before optimizing:
-
Have you measured?
- Profile first → flamegraph, perf
- Benchmark → criterion, cargo bench
- Identify actual hotspots
-
What's the priority?
- Algorithm (10x-1000x improvement)
- Data structure (2x-10x)
- Allocation (2x-5x)
- Cache (1.5x-3x)
-
What's the trade-off?
- Complexity vs speed
- Memory vs CPU
- Latency vs throughput
Trace Up ↑
To domain constraints (Layer 3):
"How fast does this need to be?"
↑ Ask: What's the performance SLA?
↑ Check: domain-* (latency requirements)
↑ Check: Business requirements (acceptable response time)
| Question | Trace To | Ask |
|---|---|---|
| Latency requirements | domain-* | What's acceptable response time? |
| Throughput needs | domain-* | How many requests per second? |
| Memory constraints | domain-* | What's the memory budget? |
Trace Down ↓
To implementation (Layer 1):
"Need to reduce allocations"
↓ m01-ownership: Use references, avoid clone
↓ m02-resource: Pre-allocate with_capacity
"Need to parallelize"
↓ m07-concurrency: Choose rayon or threads
↓ m07-concurrency: Consider async for I/O-bound
"Need cache efficiency"
↓ Data layout: Prefer Vec over HashMap when possible
↓ Access patterns: Sequential over random access
Quick Reference
| Tool | Purpose |
|---|---|
cargo bench |
Micro-benchmarks |
criterion |
Statistical benchmarks |
perf / flamegraph |
CPU profiling |
heaptrack |
Allocation tracking |
valgrind / cachegrind |
Cache analysis |
Optimization Priority
1. Algorithm choice (10x - 1000x)
2. Data structure (2x - 10x)
3. Allocation reduction (2x - 5x)
4. Cache optimization (1.5x - 3x)
5. SIMD/Parallelism (2x - 8x)
Common Techniques
| Technique | When | How |
|---|---|---|
| Pre-allocation | Known size | Vec::with_capacity(n) |
| Avoid cloning | Hot paths | Use references or Cow<T> |
| Batch operations | Many small ops | Collect then process |
| SmallVec | Usually small | smallvec::SmallVec<[T; N]> |
| Inline buffers | Fixed-size data | Arrays over Vec |
Common Mistakes
| Mistake | Why Wrong | Better |
|---|---|---|
| Optimize without profiling | Wrong target | Profile first |
| Benchmark in debug mode | Meaningless | Always --release |
| Use LinkedList | Cache unfriendly | Vec or VecDeque |
Hidden .clone() |
Unnecessary allocs | Use references |
| Premature optimization | Wasted effort | Make it work first |
Anti-Patterns
| Anti-Pattern | Why Bad | Better |
|---|---|---|
| Clone to avoid lifetimes | Performance cost | Proper ownership |
| Box everything | Indirection cost | Stack when possible |
| HashMap for small sets | Overhead | Vec with linear search |
| String concat in loop | O(n^2) | String::with_capacity or format! |
Related Skills
| When | See |
|---|---|
| Reducing clones | m01-ownership |
| Concurrency options | m07-concurrency |
| Smart pointer choice | m02-resource |
| Domain requirements | domain-* |