前回かいた Systrace (というか Ftrace) データのパース、やろうとおもいつつ procrastinate していた理由の一つは、それより Perfetto の trace processor を使う方が良いのではと思っていたからだった。が、まあ気のせいだったね。

Trace processor は Perfetto のダンプに sqlite でアクセスできる機能があり、これは魅力的である。ただ現実には自分は特別 SQL が流暢ではないので Python で regexp して Pandas で加工した方が速いし、できることも多い。例えばこのあいだアロケーションのレイテンシとサイズの相関を求めたが、その解釈にはネストした trace section を紐付ける必要がある。これは for 文で書けば自明だが SQL だとどうしていいかわからん。しかもその trace processor には Pandas インテグレーションとかがないので可視化もできない。使えねー。

より深刻な問題は Perfetto が lossy である点。Perfetto はオンデバイスのコマンドで、自分でバッファを持っている。ということは ATrace の API も Perfetto に直接フィードするのかな・・・と思いきやそんなことはなく、引き続きカーネルの trace_marker に書き込んでいる。言われてみれば atrace/systrace の動作を壊すわけにはいかないので当たり前だが、つまり Perfetto は ftrace のバッファをパースして Perfetto の protobuf に詰め替えているということである。しかもオンデバイスで！まじか。そんなことで余計な CPU サイクル使わないでくれよ・・・しかもオンデバイスなんてロジックにバグあったら直せないじゃん・・・デバイスの外でやれよ・・・。

オンデバイスでやりたいのはオンメモリのバッファでけでなくファイルに書き出す長時間トレースをサポートしないなどの事情と関係あるのは理解している。しかしトレードオフには納得できない。実際、Q のオンデバイストレース (perfetto フォーマット) を Systrace のデータに変換しようとすると失敗したり、エラーにはならないが表示が壊れることがしょっちゅうある。一方で Perfetto ネイティブなビューアは機能がたらない。だめじゃん。Perfetto Native UI は wasm とかをつかっているあたり、いかにも実用的なものをつくる気のなさを感じる。というとディスりすぎかもしれないが。

自分が Perfetto への乗り換えを考えていたのは Q から on-device tracing のフォーマットが Perfetto に変更されたからだが、こうした不利益をわざわざ受け入れる必要はないと考えを改めた。特に ATrace が引き続き ftrace に依存している事実を考えると ftrace のバッファが the source of the truth なわけで、間に lossy な Perfetto を挟むのはリスク。やめやめ。引き続き Systrace で生きていきますわ。

Perfetto は Chrome と Android 共通のインフラにすると主張している。そんなら Chrome で枯らした後で Android に持ってきてほしかった。勤務先には "a shiny but work in progress way と a functional but deprecated way がある" という格言がある。Perfetto はその一例になっている感。そういう場合は常に the deprecated way を進めというのが先人の知恵で、自分はそれを体現してしまったのだった。Sigh.

追記

Perfetto の UI がバージョンアップし、以前は表示されなかったメトリクスが見えるようになった。そして後ろの席の同僚は文句をいいつつがんばって perfetto コマンドを使っていた。そうですね我々会社員には使ってバグを踏んで報告して直させる、という暗黙の責務もあるんですよね・・・。職業倫理の差を感じる。はーつかうか・・・しかし Colab から読めねーんだよなー・・・ヒマなら業務外で Perfetto に首を突っ込みたい所だがちょっとなー・・・。