2026/01/03 20:13

Ctrl‑Cによるプロファイリング（2024）

RSS: https://news.ycombinator.com/rss

元のHacker News記事へ ↗

要約▶

Japanese Translation:

Summary

著者は、デバッガで単に Ctrl‑C を押す（高速で低頻度のサンプリング手法）が、重いプロファイラを呼び出す前に主要なパフォーマンスボトルネックを発見するには十分だと主張しています。
代表的な例は以下の通りです。

起動に約 1 分かかるデバッグビルドで、Ctrl‑C によって nlohmann JSON パーサから 10 億 のスタックフレームが明らかになりました。これを解決するには、パーサを切り替えるか、デバッグモードでも最適化を有効にする必要があります。
MIPS 上では、LLD リンカを使用すると
```
--gdb-index
```
でコアダンプをロードする際に gdb が遅くなります。
```
-ggdb3
```
を削除したことでパフォーマンスが向上しました。これは GCC の DWARF データが LLD によって正しく処理されていないためです。

著者は、デバッガはプロファイラに比べてインストルメンテーションが極めて少なく（フレームポインタや特殊ビルドフラグがなくても呼び出しスタックを表示できる）、その出力もノイズの多いプロファイルトレースよりも目で確認しやすいと強調しています。

ただし、この手法には限界があります。低頻度サンプラーであるため、細かい変化・テールレイテンシー・マルチスレッド／マルチマシン環境の問題は見逃します。また、プロファイル出力が誤解される可能性もあるため、MIPS のリロケーション緩和やリリース間での小さな回帰測定といった微妙な問題には、より洗練されたツールが必要です。シミュレーションベースのプロファイラ（例：Callgrind）は完全な命令トレースを提供しますが、本番環境では遅すぎます。トレーシングプロファイラ（ftrace/KernelShark）はテールレイテンシーを捉えますが、コード内で根本原因を特定できない場合があります。

これらの注意点にもかかわらず、Ctrl‑C プロファイルはコストが低く、試しやすく、驚くほど効果的です—特に「不親切な環境で怠惰な人々」にとって有用です。著者は最終的に “Profile with Ctrl‑C” を実際のプロファイラを使用する前の実践的第一歩として熱心に推奨しています。

本文

私は以前、プロファイラの出力が誤解を招くことについて書いたことがあります。誰かが「プロファイラは不要だ」とコメントし、デバッガで Ctrl‑C を押せば、プログラムが最も時間を費やしていると思われるスタックトレースを見ることができると述べました。私は当時その考えに嘲笑しました。ほぼ攻撃的な熱意にもかかわらず、この方法は実際には難しい問題では機能しないからです。しかし、年齢を重ねて人生観が悪化するにつれて、Ctrl‑C プロファイリングは怠け者が不親切な環境で遭遇する「ばかな」問題に対して非常に効果的だと認めるようになりました。

私はずっと「ばかな」問題を軽視し、難しいものに集中してきましたが、実際の世界ではこのアプローチは適切でしょうか？今日、私はほぼすべての人生が不親切な環境で怠け者が遭遇する「ばかな」問題だと受け入れつつあります。確かに、一度は自分自身もそのようになり、上級管理職に就き数年後に再びプログラミングに戻るという学びの経験をしました。今では何もしないことに慣れて怠けており、自分が忘れたものや以前と違う環境で作業しているため、環境が不親切です。自分自身が数多くのプロファイラを開発した者としてこれを認めるのは少し恥ずかしいですが、特定の設定でプロファイラを使いこなす気持ちになれないことがよくあります。

さて、ここに起動に1分かかるプログラムがあります――実際にはデバッグビルドのみです。おそらく誰も修正しなかった理由はそれですが、私たちは本当に修正するべきです。再ビルドして再実行するたびに1分待つのは酷いことです。そこで私は Ctrl‑C を押しました。すると何と？nlohmann JSON パーサから100億ものスタックフレームが表示されました――リリースビルドではすべてインライン化されているので「ゼロコスト抽象化」と呼ばれるものかもしれません。もう一度 Ctrl‑C を押せば、別の場所から来るが再び JSON の解析で終わるスタックトレースが出ます。修正案は何だったかわかりません――JSON パーサを変えるか、デバッグビルドでも最適化付きでコンパイルするなど―ですが、誰かが私の Ctrl‑C ベースの報告の後にそれを直しました。

たとえば LLD リンカに gold から切り替えてリンク速度を上げようとしているとします。もっと速い mold はどうですか？MIPS を使っているので mold はサポートしていません。しかし LLD もかなり高速で、同じ人物が書いたものです。その後、LLD でリンクされたバイナリのコアダンプを開くと gdb が非常に遅くなります。

--gdb-index

を追加したはずなのに、gdb のデフォルトより速くなるはずでしたが逆に遅く感じます。何が起きているのでしょうか？

そこで私は gdb 内で gdb を走らせ、コアダンプを処理しながら Ctrl‑C しました。

dwarf_decode_macro_bytes

のスタックトレースが表示されました。Google で「-ggdb3 と lld.lld をリンクすると gdb が CPU/メモリ hog になる」(未確認) や「lld は ld.bfd が生成する DW_MACRO_import を生成しない」(解決済み・修正不可) などの関連問題がすぐに見つかります。gcc は gdb が処理しにくい DWARF データを生成します。GNU リンカはこのデータを修正して gdb が遅延しないようにしますが、LLD は GNU リンカの振る舞いをエミュレートしません。gcc がその DWARF を出力したこと自体が問題です。そして gdb も LLD の出力を効率的に扱わないといけません。結局

-ggdb3

を削除しました――少し詳細なデバッグ情報は得られますが、gold と比べてリンク時間が遅くなる代わりに gdb も遅くなるだけです。みんな幸せにリンクします。

これが示すのは、Ctrl‑C プロファイリングが単純な問題を解決するには十分であり、プロファイラの使い方や出力の読み取りよりも遥かに簡単だということです。デバッガはほぼ何でも接続でき、標準 OS さえないチップまで対応できます。遅いプログラムなら

gdb /proc/$pid/exe $pid

として起動後に接続できます。

デバッガはプロファイラよりも扱う情報が少なくて済みます。perf のようなツールと違い、gdb はフレームポインタをサポートしないビルドでもスタックトレースを表示します。また、gprof の

-pg

のような特殊ビルドや Callgrind/KCachegrind のような遅いシミュレーターで実行する必要もありません。プロファイラの出力は誤解されやすく、私が最後に書いたときは表面だけしか掘り下げていませんでした。数個のスタックトレースをざっと見る方が直感的です。

ではなぜプロファイラが必要なのでしょうか？以下に理由を部分的に挙げます（順序は特になし）。

仮に LLD リンカに切り替えてプログラムが 2–3 % 遅くなったとします。Ctrl‑C を押せば gold と同じスタックトレースが得られます。しかし Callgrind のようなシミュレーターでプロファイルを走らせると、最も遅くなる関数を見つけられます――それは総時間の多いものではなく、旧バージョンに対する相対的な遅延が大きいものです。アセンブリを確認すると、新しいバージョンでレジスタからアドレスへジャンプする命令が使われている一方、古いバージョンでは定数オフセットへのジャンプが使われていたことがわかります。これにより MIPS の「リロケーション緩和」（RISC‑V でも同様）を学びます。コンパイラは最悪ケースを想定し、レジスタへ関数アドレスをロードしてからジャンプするコードを生成しますが、リンカが関数が近くにあると判断できれば、高価なレジスタジャンプを安価な定数オフセットジャンプに緩和します。あなたが使っている LLD バージョンはこのリロケーション緩和を実装していません。

もちろん、LLD 9 を使っていた私のように間違ったバージョンを選んでいるなら、その高度なシミュレーター型プロファイラは必要ありません。MIPS の知識が不十分だったためパッチレビューができず、最終的にリロケーション緩和パッチがマージされるまで数年かかったというエピソードもあります。

しかし、ここで言いたいのは、あなたが「ばかな」人である必要はないということです。プロファイラが解決できる問題を、Ctrl‑C プロファイリングでは解決できません。

より広く見ると、Ctrl‑C は実質的にサンプリングプロファイル（極端に低いサンプリング頻度）です。プログラム全体に散らばった小さな変更はサンプリングプロファイラでは見逃されます。また、テールレイテンシーには不向きです――何かが通常は高速だが時折遅い場合、遅い瞬間に Ctrl‑C できるわけがありません（たとえば「遅い」が 100 ms であっても、サンプリング頻度が低いので時間内に Ctrl‑C できない）。多くのスレッド・プロセス・マシンを含むシステムでは、「ランダムにポーズ」する手法は適切でないことが多いです。こうした理由から、Ctrl‑C をすべてのプロファイラに置き換える考えは現実的ではありません。

ただし、プロファイラにはさまざまな種類があります。シミュレーション型プロファイラは低サンプリング頻度によるデータ損失がないため、完全な命令トレースを解析しますが、本番環境での使用には遅すぎます。本番で測定できるものを取得し、その測定に基づく入力でシミュレーター上で再実行する方法が必要です。ftrace/KernelShark のようなトレースプロファイラはテールレイテンシーの例を見るには優れていますが、時間がかかっているコード箇所を確実に特定できるわけではありません。サンプリングプロファイラは本番で走らせて正しい場所へ導きますが、時折しか遅くなるコードや待機状態のコードには不向きです。また、多くのツールは設定や前提条件が複雑で、出力を誤読しやすいという欠点があります。

対照的に、デバッガ内で Ctrl‑C を行うのは簡単です。実際に機能すると非常に効果的に見えますし、失敗してもほとんどコストがかかりません。何が嫌いなわけでしょう？

私は時折、より「正しい」方法よりも優れた結果を出す原始的で醜い手法を推奨することがあります。それは典型的なユーザーの失敗リスクが低く、必要に合わせて簡単に調整できるためです。「Ctrl‑C でプロファイル」もその一例です。確かに原始的ですが、多くの場合、より洗練された代替手段と驚くほど比較可能な結果を示します。そのため私は Ctrl‑C プロファイリングに最も温かい支持を送ります！

この記事のドラフトをレビューしてくださった Dan Luu に感謝します。

同じ日のほかのニュース

一覧に戻る →

2026/01/04 1:20

**2025年におけるハッカーニュースで最も人気のあるブログ一覧**

## Japanese Translation: --- ## 要約この記事は、投稿量、総投票数、およびフロントページへのリーチで評価された2025年の最も影響力のあるHacker Newsブロガーをランキングしています。 - **Simon Willison** は、1,000件以上（118本の全文）にわたる公正なAIツールレビューに焦点を当てた投稿で3年連続王者となっています。リンクブログスタイル―短い引用やコメント付きリンクのみ—は手間が少なく高価値なコンテンツを提供します。 - **Jeff Geerling** が2位にランクインし、10,813投票を集めてわずか9ポイントで3位を抜きます。100万人以上のサブスクライバーを持つYouTubeクリエイターであり、自動生成されたトランスクリプトを避けたテキスト中心の投稿を書いて、HN上で読みやすさを高めています。 - **Sean Goedecke** が新たなパワーハウスとして登場します。2025年に140件の投稿と47件のフロントページヒットを記録し、最も人気のある「How I ship projects at big tech companies」投稿は年間トップ100に入っています。技術職への明確な意見とビッグテック組織政治の解説でエンジニア層に共感されています。 - **Brian Krebs** は常にトップブロガーとして残り、2025年には政治的に重いトランプ時代の言論自由ストーリーを投稿し、一時的に#1になりましたがモデレーションで削除されました。 - **Neal Agarwal** はインタラクティブアートとビジュアルエッセイでフロントページを支配し、投稿の約半分が#1に達します。「Stimulation Clicker」は2025年で4番目に人気のある投稿です。 - **John Gruber** が6位で終わり、2011年以来最高の一年となり、2020年以来初めてトップ10入りしました。潜在的なシャドウバンを疑問視したことで注目されました。 - **Mahad Kalam** は単一投稿リストのトップに立ち、その年で最も投票されたエントリーです；**Byrann Huang** が続き、3位の投票数を記録しました。この記事は2025年の完全なトップ100リストが別途文書化されていることを指摘し、将来の発表をほのめかしています。これらのランキングは読者がテックニュースにどのように関与するか、AI・職場文化・政治に関する議論を形作り、Hacker Newsや類似プラットフォームでのコンテンツ戦略のベンチマークとなります。

2025/12/29 1:12

**Ed25519‑CLI – Ed25519署名システム用コマンドラインインターフェース**

## Japanese Translation: ドキュメントは、Ed25519 用の lib25519 コマンドラインツールがどのように機能するかを説明しており、主に 3 つのユーティリティ―`ed25519-keypair`、`ed25519-sign`、`ed25519-open` に焦点を当てています。 * `ed25519-keypair` はランダムな鍵ペアを生成します：公開鍵をファイルディスクリプタ 5 に書き込み、秘密鍵を fd 9 に書き込みます。 * `ed25519-sign` は fd 8 から秘密鍵を読み取り、stdin（fd 0）からメッセージを読み取って署名し、署名済みメッセージを stdout（fd 1）に出力します。 * `ed25519-open` は fd 4 からアリスの公開鍵を読み取り、stdin（fd 0）から署名済みメッセージを読み取って検証し、復号された平文を stdout（fd 1）に書き込みます。検証失敗時、`ed25519-open` はコード 100 で終了し、出力は行いません；他のエラーではすべてのツールが非ゼロで終了し、成功時にはゼロで終了します。 CLI は lib25519 の一部であり、X25519 暗号化と Ed25519 署名の両方を実装しています。2 つの X25519 ツールも存在しますが、別途ドキュメント化されています。現在のドキュメントバージョンは「Ed CLI」ウェブページ用で 2024.02.18 です。関連ユーティリティには `x25519-cli(1)` と `lib25519(3)` が含まれます。これらのツールにより、ユーザーはシェルから直接暗号操作をスクリプト化したり、他言語で FFI を介して lib25519 の C API を呼び出すことで、安全な認証ワークフローをソフトウェアプロジェクトに組み込むことが可能になります。

2026/01/04 6:58

「一歩だけ踏み出しましょう」

## Japanese Translation: （全ての重要ポイントを組み込んでいます）** この文章は、大きな目標を設定すると扁桃体が闘争・逃走反応を起動し、ストレスや回避行動、進捗の停滞を引き起こすと説明しています。対照的に、目標を小さく段階的に分解することでこの反応を迂回し、不安を軽減しながら安定した行動が可能になります。実践的な戦術は次の通りです： - 「次に何をすべきか？」と自問すること； - 完全感覚でビジュアライゼーションを用いること； - 本全体ではなく1ページだけ読むこと； - ドアの近くにランニングシューズを置く（あるいは新しいものがない場合は注文しておく）ことで歩き始める。これら小さな問題―例えば靴を持っているかどうか―を解決することで、後で大きな障害になるのを防げます。靴を履いたり短い散歩を終えたりといった控えめな報酬を祝うことは進捗を強化します。毎日1つの小さなステップ（例：1週間ドアにシューズを置き、次にそれらを履く）を繰り返すことで勢いが生まれ、各行動が徐々に長距離散歩や最終的には大きな野心へと導きます。マイクロアクションの累積効果は、個人開発コーチングや職場での目標設定において、生産性と幸福感を高めるために有用であることを示しています。