(program) is Chromeそれ自体、他のすべてのコードを呼び出すツリーのルートです...ネイティブコードからJavaScriptへのジャンプ、リソースの読み込みなどが開始する必要があるため、そこにありますsomewhere:)
ツリービューの例を見ることができます Chrome開発者ツールドキュメント で。
（プログラム）はネイティブコードであり、ツリーのルートではないと考えています。
このスレッドを参照してください：
https://bugs.webkit.org/show_bug.cgi?id=88446
そのため、main（）よりもシステムコールに似ています。
どうやらそれはアイドル時間を含んでいます。また、（プログラム）のプロファイリングは、chrome：// profiler /から入手できます。
@Nickが言うように、どこかから始めなければなりません。
CPUプロファイラーの部分は、 gprofと同じ概念 に基づいている他の多くのプロファイラーのように見えます。
たとえば、selfは、編集可能なコードに大きな数字の配列のバブルソートのようなものがない限り、ほとんど役に立たない数字です。ありそうにない。
Totalには呼び出し先が含まれている必要があるため、より便利です。ただし、ブロックされた時間と実行時間の間にサンプルが取得されない限り、完全にCPUにバインドされたプログラムを除いて、それはまだ役に立たない。
これらの統計情報は、コード行ごとではなく、機能ごとに提供されます。つまり、（Totalパーセントに頼ることができる場合）、関数がそれだけ費用がかかることを意味します。それをスタブするなどして、その割合はあなたがどれだけの時間を節約するかです。
そのため、コストのかかる機能に集中したい場合は、最適化できるものを探すためにその内部を探す必要があります。そのためには、関数内のコード行間で時間を細分する方法を知る必要があります。コード行単位でコストがかかっていた場合、それらの行に直接移動します。
Zoom など、ラインレベルで報告する壁時計スタックサンプラーのように、より良いプロファイラーを取得できるかどうかはわかりません。 方法 です。