(元ネタ http://www.ilia.ws/files/zend_performance.pdf)
- staticが使えるなら、staticを使う。速度は4倍になる。
- __get, __set, __autoload は避ける。
- require_once() はコストがかかる。
- include や require では絶対パスで指定する。
- スクリプトの開始時間は $_SERVER[’REQUEST_TIME’] で得る。
- 正規表現は、文字列関数で代用できないか探る。(文字を見つけるだけならstrposなどでもよい)
- str_replace は preg_replace より早いが、strtr は str_replace の4倍早い。
- 文字列/配列両方を受け入れる柔軟さを持つ関数は避ける。変わりに個別の関数を用意する。
- @によるエラー制御は遅い
- $row[’id’] は $row[id] より7倍早い
- エラーメッセージはコストがかかる
- for ($x=0; $x < count($array); $x) の count() のようにループの度に呼ばれる関数はさけ、変数に格納する。
ねた的には、古いですがふとしたときに思い出すと良いかも。
自社のフレームワークに、こういうエッセンスを入れていくのが重要なのかな。
個人的には、require_once は使いまくりなので、どうにかコスト削減に努めたいです。（便利だからねぇ）
弊社のプログラミングの基本的な方針
便利なコード >>>>（優先順位）>>>> パフォーマンスがでるコード（コスト小）
基本的に便利なほうを優先する傾向にあります。
ここで言う便利とは、使いやすく、理解しやすく、人間的に優しいもの。という意味です。
省略したり、コードを短くしたり、難解なテクニックを使うのは、プログラマーの質によって
ムラが出るため、チームで仕事をしたりしているといろいろ弊害が出てきます。
（みんながスーパープログラマーなら問題ないけどね。。。）
この辺はシステムの要件にもよります。
普通の公道を走るのに、F1のマシンは必要ないですね。
ただし、燃費が良いほうが好まれるのは、公道でも、F1でも同じです。
このあたりの必要なパフォーマンス要件をしっかりと事前に考えて取り組むのが重要かと。
また、必ずしもトレードオフとか限らないので
「人間にもマシンにとっても優しい方法」を考えるのはなかなか楽しいものです。
得てして、人間に優しいコードは、パフォーマンス的にも良い場合が少なくありません。
そういう気質は、すぐに目の前の仕事から脱線してあらぬ方向へ行ってしまいますが、
プログラマーには、必要な「遊びごころ」だと思ってます。
0 件のコメント:
コメントを投稿