Bytecode cache

バイトコードキャッシュを用いずしてパフォーマンスを語る無かれ(超意訳)

If you care about performance and don’t use bytecode cache then you don’t really care about performance.

というほど、まず重要としているのがこの部分。
まずは(Zend社員としては当然) Zend Serverの導入検討を奨めていますが、自分でPHPをコンパイルできる環境であるならばAPCなどを使えば良いでしょう。ちなみに、このblogを動かしているPHPもAPCを使っています。GUIの管理画面もあってステータス管理も簡単。キャッシュヒット率99.9%。プログラム中からmemcache的に変数を格納したりも出来るし、非常にありがたいモジュールです。

Profiling

最適化する前にプロファイルを!(意訳)

Profile you code before you start optimizing it!

どの関数がボトルネックになっているのか、ちゃんと把握してからチューニングしましょうということで。そのためのツールとしてZend Studio/DebuggerやXdebugが挙げられています。

Caching

殆どのPHPは”shared nothing”でインストールされているわけで、リクエスト処理の終了と同時に作業内容は全部飛んでしまいます。これは処理の複雑さを回避するなどのメリットは大きいのですが、パフォーマンス的にはデメリットですよね。繰り返し処理はキャッシュに入れて、いいとこどりにしちゃいましょう。(意訳)

Most PHP installations run in “shared nothing” mode where as soon as the request processing ends, all the data associated with the request is gone. It has some advantages, but also one big disadvantage – you can not preserve results of repeated operations. That is, unless you use caching.

実際、DBへのアクセスや複雑な計算のような大きな処理はもちろん、XMLによる設定ファイルをパースしておくような簡易な処理でも、アクセス毎に発生するようであればDisk I/Oとあわせてトータルでかなりの軽量化になります。
キャッシュ先としては memcached や前述の APC などが挙げられます。用途によってはHDDでも良いでしょうが、基本的には高速なメモリでのキャッシュを考えるべきです。ポスト元では他にも、Zend Serverに含まれたZend Frameworkによるキャッシュ機能を奨めています。

Optimize your data

通常、PHPアプリケーションで最もコストのかかる処理は、データベースやファイルシステムのような外部データや、ネットワークにアクセスすることです。クエリーを減らすこと、データベース構造の改良、ファイルシステムへのアクセス減、データ取得のためのサービス呼び出しを複数回行わずに1度でまとめるなど、これらの最適化に注力しましょう。更に言えば、システムコールトレーサ(Unixであれば strace、Windowsであれば Process Explorer など)などを使い、スクリプトが呼び出しているシステムコールを減らせないかどうか検討しましょう。それらの全てを除くことは不可能だと思いますが、いくつかは検討の余地があるでしょう。(意訳)

Usually the most expensive places of the PHP application are where it accesses external data – namely, database or filesystem or network. Look hard into optimizing that – reduce number of queries, improve database structure, reduce filesystem accesses, try to bundle data to make one service call instead of several, etc. For more advanced in-depth look, use tools like strace (Unix) and Process Explorer (Windows) to look into system calls your script produces and think about ways to eliminate some of them. You would not be able to eliminate all of them but each of them is a worthy target.

ほぼ、そのまま。
下手にPHPでの処理をいじるより、RDBのチューニングを行った方が遥かに効果的なことは、非常によくあります。また、先述のキャッシュを使うような工夫は、ここにも繋がります。

Don’t try to outsmart the engine

世の中には”Tips”と呼ばれる「ああしたほうが速い」「こうすると遅い」というような話題があります。しかし特にビギナーのうちは、そういったものに惑わされない方がいいでしょう。十中八九は何も変わらず、残った1つも手持ちのコードに容易にあてることは出来ないか、費やした時間ほどの価値は無いというのがオチでしょう。確かにopcodesを軽くしたり、lookupsを減らしたりするような手法はありますが、他の全ての条件が整っていなければ無意味です。加えて、こういったアドバイスのいくつかは、寧ろコードを遅くしたり、堅牢性やセキュリティを失わせてしまったりします。特に初心者は、こういったトリッキーな手法に手を出さない方が良いでしょう。(意訳)

There are a lot of “tips” floating around about which constructs in PHP are faster or slower than others. I think you can safely ignore all of these tips, especially if you’re a beginner. Odd are, 9 cases out of 10 they won’t give you any improvement at all, and in the remaining one case it will be either not applicable in your code or not worth the time spent on it. Yes, there are ways to save couple of opcodes and remove couple of lookups here and there – but unless you’ve already done with all of the previous steps it is not worth it. And some of the advice out there will actually make you code slower, less robust and less secure without you even noticing. So I think for the beginners is better to stay away from trying to outsmart the engine altogether.

この辺が恐らく、Googleの(そして、その他「高速化Tips」と銘打つほぼ全ての)アドバイスに対する反発心に繋がっているのでは。
王道をきちんとおさえるのが近道というのは、何にでも言えることですよね。

Benchmark in real life

ここまでに話題に挙げたアドバイスの多くは、証拠としてベンチマークを使っています。問題は、これらのベンチマークはいつも、ほんの数行の部分的なコードで書かれていることです。しかしながら、実際に実行されなければいけないコードは大きなアプリケーションで、そのような一行コードではありません。(意訳)

Many of the advices I mentioned above have benchmarks as a proof. The problem is these benchmarks always test only a short piece of code. However, you would not be running that one-liner – you would be running the whole big application.

これに続けて筆者は、「勝ち馬を予想するために真空状態でのモデルを使う科学者のジョーク」を引き合いにだしています。
確かに条件が複合的に絡む場合は多く、数行のベンチマーク結果を妄信することを危惧する必要はあります。しかし、現実に「A/Bどちらの方法が速いのか?」と確かめるには、むしろ他の要因を取り払って調べる必要がある場合もあるように思います。ここに関しては、「最終的なパフォーマンスチューニングは、実際のアプリケーションを用いるべき」というアドバイスと捉えれば良いのではないでしょうか。

Leverage the extensions

あまりにも自明のことを言うようですが、それでもPHP extensionで可能となる機能を重複して作っているようなコードを数多く見かけます。PHPには多くの関数があるので、誰か他の人がやっていそうなものを作る前に、マニュアルをチェックしてみて下さい。DOM/SimpleXML拡張も、JSONパーサも、SOAP送受信のための拡張なども、利用することができます。serialize/deserialize関数が使えないのでなければ、独自のものを作ったりするのは止めましょう。
もしパフォーマンスが非常に重要で、あなたがCプログラムを書けるなら(PHP初心者が、全てにおいて初心者だということを意味しませんよね)、独自のPHPエクステンションを作ることを検討してみてください。それは、それほど難しくはありません。(意訳)

That seems too obvious, but I have seen a lot of code that duplicates functions available in some PHP extension. There are a lot of functions in PHP and if you do something that others may have done before, check in the manual. You have DOM/SimpleXML extensions for XML, JSON extension for JSON, SOAP extension for doing SOAP, etc., etc. Do not create custom serialization/deserialization if serialize()/deserialize() would work for you.
If you have some very performance-sensitive bit of script and you can do C programming (beginner in PHP doesn’t mean beginner in everything , consider even making your own extension, it’s not that hard.

Avoid extra notices/errors/etc.

PHPでエラーを抑止することが大変だったとしても、noticeやstrict notice、warningなどが出ないコードを書くよう挑戦してみて下さい。その際、全てのエラーが出力されるように設定したいと思いますが、実運用環境ではエラー表示を決してしないようにしましょう。恥を大っぴらにするだけですから。(意訳)

Even suppressed errors have cost in PHP, so try and write your code so it would not produce notices, strict notices, warnings, etc. You may want to enable logging of all errors to examine that. Never enable displaying errors in production though – it will only lead to a major public embarrassment.

変数の未定義や配列に添え字が無い場合など、noticeエラーを出しておくことは、タイポなどの単純で気付きにくいバグを回避するのに有効です。ちゃんと無くしましょう…と心から思うのですが、一方で「それってスクリプト言語の手軽さ」を失うことでもあるのかなと考えてしまいます。
いっそ変数型宣言必須の”strict mode”みたいなのが欲しいような。

Use php.ini-production as a start

もしphp.iniの設定をするのに、PHPのソースコードに含まれる php.ini-production を参考にしましょう。include pathなど幾つかの項目は変更が必要でしょうが、土台にするには最適です。(意訳)
If you need a set of php.ini settings which would not hurt your performance and not break anything, look into php.ini-production in PHP source. You may need to change a couple of details (e.g. include path) but it’s a good starting point.
マニュアルによると、PHP5.3.0からはphp.ini-development(開発環境用)、php.ini-production(運用環境用)の2つが同梱されているようです。自分はまだPHP5.3を落としていませんが、以前のrecommendedなどとどの辺が違うのか、確認してみようと思います。

Use big realpath cache

リアルパス・キャッシュは、ファイル名や相対パスからユニークなフルパスを取得する際に非常に有用です。初期設定ではこのキャッシュサイズは16kですが、多くの長いパス名のファイルを扱うのであれば、この値を増やすのが良いでしょう。これはディスクアクセスという重い処理を軽減します。(意訳)

Realpath cache is very useful for the engine when it tries to find the unique full name of the file from just filename or relative path. By default, it’s 16K but if you have a lot of files with long pathes, it’s better to increase the size – it would save the expensive disk accesses.

この機能はPHP5.1から実装されたものですが、ちょっと大きい規模のアプリケーションになると、16kという値はすぐに超えてしまうかもという話は、よく聞きます。よほどメモリに困窮していなければ(そんな場合は既にパフォーマンスを云々言っていられないと思いますが)、64kくらい確保してしまうのが良いようです。

最後に、次のように締められています。

ここに挙げた以外にも、もっと多くのことが挙げられると思いますが、既にちょっと長くなりすぎました。一旦ここで終わりますが、あなたの考えをコメント欄で追加してくれると嬉しいです。

There are probably more things that could be said, but this post is pretty long already, so I will end it here and you are welcome to add your opinion in comments.

同じ言葉で、終わりたいと思います。

No related posts.

知識として「ふーん」という以上には役立たないTipsの、PHPにおける最右翼はこのechoとprintの速度差問題ではないでしょうか。前回挙げたGoogleのページでも、公開当初はあったものの、後に消されたエントリの1つです。
Smartyなどのレンダリングエンジンに慣れていれば、そもそもデバッグ時以外では使わない場合も多いこのステートメントの「速度差」が、果たしてどの程度のものなのかを確かめてみます。

大きな文字列を出力

1Mほどの大きな文字列を出力させてみます。

$s = str_repeat('x', 1024 * 1024);
echo $s."\n";
print $s."\n";
print $s."\n";
echo $s."\n";

実行順序で結果が変わることがあるので、2回ずつ呼んでみました。

echo: 0.005774974823
print: 0.00450992584229
print: 0.0048840045929
echo: 0.00483393669128

誤差の範囲しか、違いを見出すことは出来ませんでした。

繰り返し出力

256bytesほどの文字列を、繰り返し出力させます。

$s = str_repeat('x', 256);
$cnt = 10000;
for($i=0; $i<$cnt; ++$i)
  print $s."\n";
for($i=0; $i<$cnt; ++$i)
  echo $s."\n";
for($i=0; $i<$cnt; ++$i)
  echo $s."\n";
for($i=0; $i<$cnt; ++$i)
  print $s."\n";

print: 0.0117089748383
echo: 0.0106270313263
echo: 0.0104529857635
print: 0.0104429721832

こちらも、わずかに echo の方が速いと言えるかもしれない程度です。

速度差を気にする必要は無い

気にしなければならないほどの速度差は、無いと判断します。
PHP自体のCのソースコードを読めば、printの方が少し余計な処理をしている分だけ遅いのが道理ですが、意識しなければいけないほどではありません。
OSなど標準出力の機構によってはもう少し大きな差が出るケースがあるのかもしれませんが、基本的には動作・シンタックスの違いだけを気にしておけば良いと思います。(これすら、実際には使い分ける必要はまず無いと思いますが)
一応、簡単に違いを挙げておきます。

echoとprintの違い(1) 文法

どちらも関数ではなく言語構造である点は共通しているので、括弧なしに呼ぶようなことが可能です。しかしprintの方が、比較的関数に近しい記述を許されています。
例えば、次のような記述はechoでは出来ません。

$ret = $flag ? print 'true' : print 'false';
echo "return code: $ret";

このコードは、標準出力が成功すれば$flagの値がどうあれ”1″を返します。

echoとprintの違い(2) 引数

echoは複数の引数を取り、これを連続して出力することが出来ます。

echo "x", "y", "z";
print "x"."y"."z";

カンマで渡した方が、若干高速なようです。(これもよくきくオカルトですし、実際に逆の検証結果もあるようですが、自分の方で試した結果はやはり文字列結合より引数渡しの方が、やや速いようでした)

Related posts:

1. [PHP] 高速化Tipsのオカルト(1) 関数への参照渡し

先日は、にわかに高速化づいているGoogleも、サイト高速化に関するコミュニティをオープンさせました。その中には、PHPに関するパフォーマンスTipsも含まれています。ところが、これも「オカルト」に毒された誤った内容が多く指摘され、公開から僅か1週間で何度も書き直されるような事態になっています。

ここでは巷間に溢れるPHP高速化Tipsの幾つか怪しいものを検証してみます。
※なお、検証に使ったPHPのバージョンは5.2.9です。

大きな配列はポインタで渡す?

PHPには厳密な意味でのポインタは無く、zvalのリファレンスということになりますが。
関数内で元の変数を参照するだけの場合でも、変数のコピーが行われないように参照渡しにする開発者を見かけます。しかし、少しPHPの内部構造を学べば、copy-on-writeの仕組みによってその必要が無いということを知っていると思います。
しかし、実際にはやはり値渡しとポインタ渡しは、値の変更が無かったとしても「同じ」ではありません。
関数内での変数の扱い方によって、速度が変わることを確認してみましょう。

foreach

まずは、foreachを使って大きな配列にアクセスしてみます。

function test1($a){
  $c = 0;
  foreach($a as $v){ if($v=='xxxxx') ++$c; }
}
function test2(&$a){
  $c = 0;
  foreach($a as $v){ if($v=='xxxxx') ++$c; }
}
$x = array_fill(0, 1000000, 'xxxxx');
test1($x);
test2($x);

時間を測るあたりのロジックは割愛しますが、以下、結果です。

time: 0.627353906631
time: 0.374164819717

参照で渡した方が速くなっています。これは結局、test1でforeachが値のコピーを作る際に配列全体のコピーを行ってしまうためです。メモリ使用量を考えても参照渡しの方が優位ですが、これほどの巨大な配列でなければ気にするほどではないと思います。

for

次に、foreachではなくfor文を用いて、変数のコピーを行わずにアクセスするパターンを見てみましょう。

function test1($a){
  $cnt = count($a); $c = 0;
  for($i=0; $i<$cnt; ++$i)
    if($a[$i]=='xxxxx') ++$c;
}
function test2(&$a){
  $cnt = count($a); $c = 0;
  for($i=0; $i<$cnt; ++$i)
    if($a[$i]=='xxxxx') ++$c;
}
$x = array_fill(0, 1000000, 'xxxxx');
test1($x);
test2($x);

処理としてはforeachのものと同じです。結果は、次のようになりました。

time: 0.508368015289
time: 0.736795186996

処理速度が逆転してしまっています。これは逆にメモリコピーが行われなくなれば、リファレンスやfunction-stackの追跡が挟まる分だけ少し遅くなってしまうということです。

for + count

更に、もう1つ確認してみましょう。

function test1($a){
  $c = 0;
  for($i=0; $i<count($a); ++$i)
    if($a[$i]=='xxxxx') ++$c;
}
function test2(&$a){
  $c = 0;
  for($i=0; $i<count($a); ++$i)
    if($a[$i]=='xxxxx') ++$c;
}
$x = array_fill(0, 10000, 'xxxxx');
test1($x);
test2($x);

countをループの外に出さず、毎回評価しています。これも高速化Tipsの基本ですが、ついつい手抜きをして、このようなコードを書いてしまう人も多いのでは。
この実行結果は、次の通りです。

time: 0.00851798057556
time: 20.5319070816

驚くべき結果になりました。
実はこのテスト、前のものに比べて配列のサイズを2桁下げています。test1の所要時間が短くなっているのはそのためで、決してこちらの書き方が高速というわけではありません。
それにしても、このtest2の眼を疑うような劣化ぶりは、どうしたことでしょうか。良かれと思ってわざわざ参照渡しにしたはずが、悲惨なまでにパフォーマンスを劣化させる結果になってしまいました。

結論としては、関数内で値を直接変更しなければいけないような必要性が無ければ、PHPのcopy-on-writeに委ねたコーディングをするのが正解だと思います。
そして、countはちゃんとループの外に出しましょう

Related posts:

1. [PHP] 高速化Tipsのオカルト(2) echoとprint

値渡しでも、ポインタが渡される

T君は、関数に大きな配列を渡す際に参照渡しにしてくれていました。
メモリコピーのオーバーヘッドを無くすためです。

function get_value(array &$a){
  return $a[0];
}
$a = get_big_array();
$v = get_value($a);

こういった意識・心がけは非常に良いことなのですが、実はPHPにおいて、このケースは値渡しでも参照渡しでも同じ挙動をします。
確認してみましょう。

function byVal(array $a){
  echo memory_get_usage()."\n";
}
function byRef(array &$a){
  echo memory_get_usage()."\n";
}
$a = get_big_array();
echo memory_get_usage()."\n";
byRef($a);
byVal($a);

$aは50kほどの大きさです。値渡しの際にメモリコピーが行われるならば、byVal関数を呼んだ際にメモリ使用量が50kくらい増えるはずです。
実行結果を見てみましょう。

2538312
2538408
2538456

メモリ消費量はほとんど変わっていません。

値渡しされた変数の値がコピーされるタイミング

このように、PHPでは関数に変数を渡しても、その場でコピーされるわけではありません。
しかしあくまで「値渡し」ですから、関数内のスコープで値が変更された際に、呼び出し元の変数値を変えてしまうことはありません。
つまり、値はちゃんとコピーされ（てしまい）ます。いつでしょう？
関数内で「値を変えようとした際」にコピーされるのです。

確認してみましょう。

function byVal(array $a){
  $x = array_shift($a);
  echo memory_get_usage()."\n";
}
function byRef(array &$a){
  $x = array_shift($a);
  echo memory_get_usage()."\n";
}
$a = get_big_array();
echo memory_get_usage()."\n";
byRef($a);
byVal($a);

先ほどのテストとほぼ同じですが、関数内でarray_shiftを呼び、配列の値に変更が入るようにしてみます。

2538464
2539888
2586808

値渡しの際に、メモリ利用量が増えていることが確認できます。

まとめ

関数で配列やオブジェクトの値を参照だけする場合、明示的に参照渡しにする必要はありません。
寧ろ、値が変更された場合の事故を防ぐためにも、参照渡しにすべきでは無いとも言えます。
しかし一方で、渡された値に対して値渡しであることで安心して変更を加えると、思わぬオーバーヘッドが発生してしまうこともあります。

function byVal1(array $a){
  $a[0] .= 'A';
  return $a[0];
}

function byVal2(array $a){
  $x = $a[0] . 'A';
  return $x;
}

$a = get_big_array();

$s = microtime(true);
for($i=0; $i<100000; ++$i){
  byVal1($a);
}
$e = microtime(true);
echo $e-$s."\n";

$s = microtime(true);
for($i=0; $i<100000; ++$i){
  byVal2($a);
}
$e = microtime(true);
echo $e-$s."\n";

30.0323519707
0.145305156708

2つの関数は結果として同じことをしていますが、経過として配列のコピーが行われるか否かで200倍以上の差が出ています。
こういった点を注意しようと思えば、結局のところ挙動をしっかりと意識しなければなりません。

• 実行結果の事故を防ぐため、必要に迫られない場合は値渡しにする
• 値渡しであっても、不必要にコピーが行われないように意識する

という、ある意味矛盾した方針でコーディングしていくのが良いと思います。>T君

追記
メモリ利用量ではなくパフォーマンスの角度から、別のエントリを書きました。
関数内でforeachを用いるとメモリコピーが行われること、値そのものへのアクセスは参照渡し(リファレンス渡し)の方が寧ろコストがかかることなどを検証しるので、参考にしてください。

Related posts:

1. [PHP] 高速化Tipsのオカルト(2) echoとprint
2. [PHP] bitの異なるOS間でのserializedデータ交換

現象

64bit OSから、例えば次のようなコードで、配列をシリアライズして memcache に保存します。

$x = '1062430001292';
$a[$x] = $x;
$v = serialize($a);
$m->set('test', $v);

本来 memcache::set を使うなら serialize 不要ですが、ここは分り易くするために。
で、この値を32bit OS側から取得してやります。

$v = $m->get('test');
$a = unserialize($v);
print_r($a);

すると、結果は次のようになってしまいます。

Array
(
    [1573079180] => 1062430001292
)

添え字と値は同じものを指定していたはずですが、全く異なる値になってしまいます。

原因

書き込む前の、64bit OS上での $a を var_dump してみます。

array(1) {
  [1062430001292]=>
  string(13) "1062430001292"
}

そして、serialize した $v の値を見てみましょう。

a:1:{i:1062430001292;s:13:"1062430001292";}

一見良さそうですが、問題点が潜んでいます。

a:1:{i:1062430001292;s:13:"1062430001292";}

そう、添え字が int となってしまっています。
明示的にキャストしたり、色々と試してみましたが、添え字の中身が全て数値の場合はどうしても int と識別してしまう様子。
そのため、32bit OSの int では桁が足りず、32bit分だけの数値になってしまうワケですね。

対処方法

我々のプロジェクトでは、添え字の値は捨てることで対応可能でした。
しかしいつもそういった対応が可能とは限りません。
出来るならば、例えばアタマに “id” と付けるなど、イヤでも文字列になるような対処も方法のひとつだと思います。

$x = '1062430001292';
$a["id:{$x}"] = $x;

それも難しければ、serialize した後で文字列に無理矢理変換する方法もあるかもしれませんが、オススメはしにくいですよね。

a:1:{i:1062430001292;s:13:"1062430001292";}

↓

a:1:{s:13:"1062430001292";s:13:"1062430001292";}

Related posts:

1. [PHP] 配列やオブジェクトの値渡しと参照渡し

if ( $a and $b ) echo "it's true!\n";
if ( $a && $b ) echo "it's also true!\n";

先日、両者の違いについてチームで話題になったので、ちょっとまとめ。

Quick Questions

次の問いにサクサク答えられれば、バッチリ理解しているということで無問題かと。
回答は全て、$xが真(true)か偽(false)で。各問いをクリックすると、答えがわかります。

1. $x = (true and false);
2. $x = true and false;
3. $x = false and true;
4. $x = (true && false);
5. $x = true && false;
6. $x = false && true;
7. $x = (false or true);
8. $x = false or true;
9. $x = true or false;
10. $x = (false || true);
11. $x = false || true;
12. $x = true || false;
13. $x = (false and true or true and true);
14. $x = (false and true || true and true);

さて、正解率はどれくらいだったでしょうか？

解説

まず誤解の無いようにしておくと、論理演算子としての意味は and でも && でも変わりません。共に論理積です。
では、何故このような違いが起きるのでしょうか。
そのポイントは、演算子の優先順位にあります。

例えば「2」の問題、パッと期待してしまうのは、「true and false」という論理式の結果である「false」が$xに代入されることだと思います。

$x = true and false;

しかし、PHPにおける論理式の優先順位は “&&” > “=” > “and” の順です。
つまり、この式はまず「$x = true」が評価されて代入され、その結果とfalseの論理積を計算する（結果はどこにも代入されない）ということになってしまいます。

逆に、同じ式に見える「5」の問題では、”&&”の方が”=”よりも実行順位が高いため、論理積の結果が$xに代入されるようになります。

$x = true && false;

こうして考えると、全ての問題に納得がいくでしょうか。

念のため、最後に挙げた「13」「14」について見ておきましょう。

$x = (false and true or true and true);
$x = (false and true || true and true);

“and”と”or”が並んだ場合、優先されるのは”and”です。
そのため、「13」では次のように評価され、結果は”true”となります。

$x = ((false and true) or (true and true));

しかし、”and”と”||”では、優先順位は”||”の方が高くなっています。
そのため、「14」では次のように評価されてしまいます。

$x = ((false) and (true || true) and (true));

結果は、”false”になります。

まとめ

括弧を省略せず、明示的に書く癖をつけることが第一です。

そして、同じチーム内では”and”と記述する人と”&&”と書く人が混在しないように、コーディングルールなどにしっかりと明記すべきでしょう。
さもないと、チーム内で他人のコードを編集した際などに、最後の14問目のような思わぬ不具合を招く可能性があります。

新メンバーを向かえた際などについ、「そんなの、どっちでもいいじゃん」となってしまうこともあります。
単なるコード表記上の美学ではなく動作の安全性にかかわることなので、しっかり統一することをオススメします。

Related posts:

1. [PHP] 配列やオブジェクトの値渡しと参照渡し
2. [PHP] 高速化Tipsのオカルト(2) echoとprint
3. [Javascript] nullとundefinedとfalseと0と空文字と