トレースAPIの調査
そろそろスクリプトのパフォーマンス測定をしたい事が増えてきた。
例えばゲームなら ゲームロジック→頂点演算→頂点リスト生成(VBOのバッファ)→頂点キック の各ステージでどれくらいの時間を食っているかを知りたい。
もちろんVMのプロファイラも考えられるが、基本的にnmoshで書かれるプログラムは他のネイティブコード部分が支配的なのでそれらもinstrumentしたい事が多い。このため、必然的にsystem wideなトレースAPIへの組み込みを考えることになる。
(ここではCPUプロファイラのことはとりあえず考えない。例えば、Very sleepyのような時間的/統計的プロファイラとかVTune、CodeAnalystのようなCPUプロファイラとVMの統合はなかなか難しい問題でまだまだ調査が必要。)
DTrace
この手のAPIで一番充実を誇っているのはDTraceだろう。DTraceはMacOSやFreeBSD、Solarisで使用出来る。オラクルによるLinux移植も有るが、使ったことがない。JoyentはRuby DTrace( https://dev.joyent.com/projects/ruby-dtrace/wiki/Ruby+DTrace )を導入し、これはAppleのRuby配布に含まれている。
libusdtはもっと興味深いプロジェクトで、トレースポイントをJust-In-Timeに生成し、組み込むことができる。libusdtはRubyを始めLuaのような他のスクリプト言語にもbindingがある。
SystemTap
SystemTapはDTraceと互換性のあるユーザランドProbeを含めることができるが、このprobe(USDT)はダイナミック生成できない(?)。最近リリースされたLinux 3.5以降ならUprobesが有るが、今のところlibusdtのようなパッケージは無いように見える。
Uprobes(を始めとした多くのprobeシステム)は平たく言えばブレークポイントなので、原理的には動的に生成出来る。ただし、probeの"素性"(パラメタの名前やデコード方法など)を注入するのが地味に面倒なことが多い。libusdtはこの部分をパッケージ化している。
Event Tracing for Windows
Event Tracing for Windows(ETW)はVista以降のWindowsにあるイベントトレースフレームワークで、ユーザランド/カーネルモードの両方にAPIを提供している。
イベントを提供するにはアプリケーションのmanifestに含める必要がある。逆に言えば、イベントの種別を動的に生成するには向かない。旧来のWMIベースのEventは使用できるかもしれない。
WindowsのEvent TracingはDTraceやSystemTapと異なり、単純なイベント収集とフィルタリングしか行えない。SystemTapやDTraceはそれなりに複雑なprobe操作を(型安全な)スクリプト言語で記述することができる。Windowsではその手の高度な機能はConsumerやWMIに備えられている。ただ、WMIは通常のヒューマンには理解しづらい。
