今は主に性能改善の仕事をしていて、代表的なメトリクスについて性能改善をしたり regression を直したりしている。が、ある種の退屈さがある。たぶん自分の実力不足のせいなので文句は言えないのだが。

自分はやっている性能改善は、たとえばアプリの起動のような一瞬で終わるべきものがちゃんと一瞬で終わるようにする、という種類のものである。どうにもならないくらい遅いものをガツンと速くするような仕事ではない。

アプリ開発だと、こういう「すでにまあまあ速いものを速く保つ/更にもう少しだけ速くする」仕事は、割と打ち手が決まっている。投機的になんかする。逆に不要な処理(特に初期化)を lazy にする。クリティカルパスを見つけて不必要なものを別スレッドに追い出す（並列化する）。ラクするためにさぼっていた部分を汚く速くする (例: Layout XML の inflate をやめて Java にハードコードする, 無意味な future chain をまっすぐなコードに直す)。キャッシュする。要するに Systrace を睨んでブロックを移動したり、さぼりででかいブロックを縮めたり。なんというか、割と定型的。そしてガツンとは速くならない。

もちろん他人よりツールに精通することで遅さへの視力を高めることはできるのだけれど、視力を高めても細かいところが見えるようになるだけなので、より細々した高速化ができるようなりはすれどガツンとはしない。たとえば自分は Systrace やプロファイラ, dumpsys などは詳しい方だと思うしベンチマークの流し方もまあまあわかってる。それはそれでいいことなんだけど、どうしてもけちくさくなりがちなのだよな。

前のチームでは、人手不足で速度を見る人がいなかった。だからガツンと速くなることがあった。そして自分のブラウザ知識を WebView に転用して傍目には自明でない高速化をすることができた。サーバ側ふくめ end-to-end でさわるのも効いた。今のチームのコードはもともとそれなりに速いし、チーム内で自分しか持っていない知識というのもない。チームの境目を越えて動き回る力もない。だからガツンと速くすることも、自明でない高速化もできない。

アプリに改善の余地がない、という話ではない。たとえばある UI のまわりには以前からちょっとした遅さがあった。それが遅いことは自分ふくめみな知っていたのだが、interaction 仕様の都合であまり速くできなかった。けれどある日 UI を中心にみているプログラマがその遅い UI の挙動自体をちょこっと変えて速くなるプロトタイプを作り、UX のひとと話をしながらぱぱっと iterate して整合性を整え、コードを入れた。結果その機能ははっきりと体感できるほど速くなり、めでたしめでたしとなった。

こういう変更がしたいよなー。自明でない形で目に見えるくらい何かを速くしたい。

ただそのためには、アプリ本体やその依存先のコードに詳しくならないとダメだよなあ。読むだけでなく、書くのにも参加してないときびしい。ある程度 big picture をもち、上からガツンを書き換えて速くするみたいのが必要。速くなった UI にしても速くしたエンジニアは a lead としてコードをレビューしており、デザインをよくわかっていた。たぶんバグもぼちぼち直していた。

そういう意味では高速化ばっかりやっていないで機能開発もやってコードを内面化し、それから速度について振り返るほうがよいのかもしれない。

Platform の中の人としての performance team というのもあって、これはサーバサイドの同種の仕事にけっこう似ている。ブラックボックスである沢山のアプリの相互作用をシステムとして分析/推測し、なんかわからんが遅いとかいう問題の原因を探り当てる仕事。難しい仕事だしクライアントサイド性能改善の専門家として尊敬できる人たちだけれども、自分がやりたいのはこれではないとも思う。

アプリケーション側のプログラマとしてスタックを細部まで理解し、そいつの力を引き出すようなコードを書く。それが速い。パフォーマンスの専門家に頼らず、自分のコードは自分で速くする。そういうのがよい。

が、これは自分の今の仕事とはだいぶズレてるね。いまの自分はパフォーマンスの専門家のしょぼいやつ、というかんじだから。ほんとはもっとたくさんコードを書いて重要なサブシステムを own し、その上でちゃんと速いアプリにする、というのがあるべき姿なのだろう。今の自分からはだいぶ遠い話なあ・・・・。

Sigh.