正直言うと未だにHTTP::MobileAttributeの中身であるClass::Componentを分かってない。なのでできることも限られてるわけだが。

今回のミニ祭りを見ていてよくわかるのは結局のところスピードに最も影響があるのは端的なコードの書き方ではなく構造（ストラクチャ）を見直す事であるというだ。id:tokuhiromのところでパフォーマンスチューニングの結果を追ってる人はわかると思うけど、結局俺が参加したのはもう本当にコードの書き方をチューニングするというレベルのところで、例えばループをアンロールしてif/elseで実装してみるとかね。でもそこはどんなにがんばっても数%のパフォーマンスゲインにしかならない。

だが、例えばプラグインの読み込みのタイミングを変える事や、Class::Componentの中身をいじってメソッドの呼び出し回数を変えてみるというようなそもそもコードの構造が変わるようなところをいじると10%~20%でパフォーマンスが変わってくる。

今回はベンチマークを取りつつ、perl -d:DProf hoge.pl && dprofppの結果を見ながら最適化できるところを追って行ったが、それでもこんな感じだ。例えばinstance_clear()というメソッドがあったのだが、これをいくら速く実装してもせいぜい2%の最適化。だが、そもそも構造を変えてこのメソッドをいらなくすれば10%くらいスピードが違ってくる。

さて激しく既出だが、これから得られる教訓は

あたりだと思います。

４はプログラミングに慣れてくればくるほど気をつけなければいけないところだ。最適化を気にするあまりまだちゃんと動いてもいないのに、先に最適化をしてしまう／考えてしまうような事をしているとコードがそもそもかけなかったり、コードがガタガタになったりするので要注意。

５は言わずもがな。そもそも構造に問題がある可能性がある状態なので、最適化する時にコードをぶっ壊してたらもともこもない。実際今回自分も何回も最適化の途中でコードをぶっ壊したけど、id:tokuhiromが先にいっぱいテストを用意してたから問題なかった。

そして今朝起きてみたら普通にパフォーマンスが昨夜俺が残した部分から５０％くらいあがってた。素晴らしすぎる。

今朝のDProfを見る限り、あとはClass::Componentの一部とかくらいしか問題がないように思える。

＃ 私信：Class::Component::__ANON__が結構上にあがるんだけど、DEBUGモードかなにかの時だけにSub::Name使って動的に生成される関数に名前をつけることは可能だろうか？