APCいろいろと、「stat()を呼びまくるのを眺める」の補足 (解決はできてない)

以前のエントリなのですが、バーコードリーダー萌えのkuせんせいから、そもそもstatって重いのか、と聞かれました。
そうなのですよ。確かに、statをいっぱい呼んでいることは分かるのですが、その処理が重いのかってのを知らないのです。PEARモジュールを普通に使うだけでも、statの数は軽く500を超えたりするので、「ちりも積もれば、」なんでしょうが、その「ちり」のコストがどれくらいなのか。
実際のところ、OSレベルでキャッシュかかったりもするので、自分は良くわからんのです。BSDとLinuxでも違いがあるかもしれないし。

realpathチェックを外して驚きの早さ30%アップ！な

http://papelipe.no/tags/php/optimizing_php_for_intel_based_mac

の記事では、FreeBSDが重いよと書いているようにも読み取れます。

いろいろ実験してたのですけど、まだ、きちんとした結果を出せてないです。はい。どう実験したらよいか考えてるところであります。
いろいろ読んでみた資料を以下に書いておきます。

apc@facebook

次のエントリでまとめた

Building Scalable PHP Applications

OmniTIのGeorge Schlossnagle氏がZend Conferenceで発表したスライド。

Building Scalable PHP Applications (PDF)

この中の "10 Best Practices" の2つ目、 "Control your include trees to no more than 10 includes." (p.14)には以下のようにある。

Including a file is expensive, even when using a compiler cache.

Path resolution must be performed, resulting in at least one stat() and a realpath() call.

A reasonable number of includes is fine (and promotes good code organization), but 25, 50, 100+ will impose a real performance penalty.

I stick to 10 as my personal metric.

ってことで、

ファイルのincludeはコストが高い。コンパイラキャッシュを利用しているときでさえ。
パス解決は必ず実行され、これにより1回以上の stat() と 1回の realpath() が呼ばれる

ということだから、APCのキャッシュ利用前にパス解決で呼ばれてしまうということか！

PHP Secrets

Derick Rethans - PHP Secrets (PDF)

PHPのopcode変換の話や、コンパイラキャッシュについてなど
スライドのおまけページに書いてある、PHP内部での、変数のリファレンスの挙動の絵がいい感じです。

おすすめの本 "Advanced PHP Programming"

Opcodeの変換の話なんてところまで書いてある書籍なんて、皆無だと思いますが、"Advanced PHP Programming" では、そんなことまで書いてます。(上のGeorge Schlossnagleの著書で、洋書です。。) 目次を見てもらうと分かるように、コーディングスタイル、OOPから始まり、デーモンの書き方、パフォーマンスチューン、ZEND Engineの仕組みからExtensionの書き方まで、えらい守備範囲です。おすすめです。
8月にsecond editionが出るようです。現在発売されているfirst editionは、2004年2月の発売ということで、PHPのVersion 5.0.0 Beta 4が出た頃 (RC1すら出てないころ)に出版されており、だからといって、内容がダメなんてことは無いのですが、現在の状況に合わせて書き直されると、ますますよくなるかなと思ってます。