先週末、ちょっとしたプログラムをGAE/Jで動かして実際に使ってもらってみたのですが、そうすると、いままでテストでちょこちょこやってたときには全部のDaily Quotaが0%だったものが、数%の数字を示すようになります。
これを、ちゃんとプロモーションして多くの人に使ってもらおうとすると、課金が発生したり制限にひっかかったりしそうです。
で、たとえばDatastore APIの呼び出し回数がヤバいとして、API呼び出しを減らすためにキャッシュしようとすると、MemcacheのほうのAPI呼び出し回数がヤバくなってきます。
で、じゃあということでデータストアにデータを置くようにすると、保存量の制約で課金がかかってきます。で、それならと、データストアに置くのはシリアライズしたデータにしてデータ量が最低限になるようにすると、今度はその処理をするためのCPU時間で課金がかかってきます。
コードを書くとき、ひとつひとつの処理について、その処理がどのくらい呼び出されるか、そこで課金は無駄に発生しないか、制約に引っかからないかというのを考えるようになります。
たぶん、それを気にし始めたばかりなので過剰な反応ではあるのですが、割り算をひとつ書くのに、「これって必要だろうか？」とか考えたりもしました。ぼくはZ80アセンブラで育ったので、割り算というのはマシンステートを食うという考えがいまだにあったりするのもあります。
いままで、このような問題があると、便利なライブラリやフレームワークを持ってきて解決することができました。でも、便利なライブラリやフレームワークは、CPU時間を余分に食うのです。
たとえば、困ったらキャッシュしておけばおk、という安易な解決策は通用しません。すべての場合に通用する解決方法がないのです。
そこで、ちゃんとその処理の使われ方の傾向や、処理自体の性質を考えて、その処理にあわせた解決を行う必要があります。
さらには、仕事での開発なら、その開発工数と、Googleへの課金がバランスするかというのも考える必要があります。
最近では、相当負荷のかかるような処理じゃない限り、効率のいいコードを書いたとしてもそれが商売上の数字として効果がでることはありませんでした。最終的に、ある入力にたいして妥当な出力が得られれば、効率がいいか悪いかはほとんど気にされることはありませんでした。
でも、Google App Engineでは、赤裸々な数字として表がでます。ある意味、Google App EngineのQuotaの表と言うのは、プログラマの成績表です。
同じ処理なら、コードがきれいとかモデルとして美しいとかではなく、あの数値が低い方が勝ちなのです。もちろん仕事のコードならメンテナンス性も気にしておく必要があります。
恐らく、Google App Engineの課金をちょっとさげたら給料があがる、というようなことはないかもしれませんが、それでも、効率の良いコードが評価されるという指標がでてきたのは、プログラマとしていいことだと思います。
