『「@」でエラー抑制すると PHP が遅くなるという噂について』
http://blog.myrss.jp/archives/2008/05/_php.html

実際に遅くなるというのを計測したのは始めて見ました。遅くなることも知りませんでした。後から見るとPHPマニュアルのコメントにもいろいろ書いてあるんですね。

これから派生していくつか議論が出てきているようで面白いですね。
http://d.hatena.ne.jp/koyhoge/20080509/ignore_error
http://neta.ywcafe.net/000852.html
http://beatnik.jp/blog/archives/26
http://programming-magic.com/?id=160
http://www.developer0000.jp/2008/05/10/2358/

と、読んでいて気になった。なんだか、こんな議論しか出てきていないように見える。
「@遅い→使うのやめよう」
「盲目的に使わなくするのは、かえって可読性を下げる」
「もっと他にやることがあるんじゃないか」

いやいや、まずは @ が遅いという事実を受け入れることが肝心ではないでしょうかね。そもそも何で遅くなるんですかね？「エラー処理しなくていいんだから処理を省けるよね。当然速くなるはずだよね」とか思わないんでしょうか。

調べてみました。

zendエンジンの構文解析段階で、@ 演算子はzend_do_begin_silence と zend_do_end_silenceで囲まれることになっているみたいです。で、ZEND_BEGIN_SILENCE_SPEC_HANDLER では error_reporting を 0 にして、ZEND_END_SILENCE_SPEC_TMP_HANDLER で元の値に書き戻すことをしています。

つまり、php で書くとこんなイメージ。
for($i=0;$i<100000;$i++){
$x=ini_get('error_reporting');
ini_set('error_reporting',0);
$b=$a['c'];
ini_set('error_reporting',$x);
}

…これは遅くなりそうだ。実際には上のまじめな PHP スクリプトを実行するよりは高速に処理されますが、概要はこういうものでした。

ただしこれは zend エンジンの話なので、ひょっとして zend の気まぐれでこの処理が抜本的に見直されて、「@ 使ったほうが速いよ！」みたいな事態にならないとも限りません（たぶんならないと思うけど）。だから「@ が遅いかどうか」というのは、必ず「現在の PHP の実装では」という前提がつきます。

余談ですが parsekit extension 使うと、もうちょっと PHP 的に調べることもできそうですね。

～～それはさておき～～

「@ は使わないようにするよ」→大いに結構。ちゃんとエラー読もうね。
「@ を isset に置き換えるよ」→うむ。
「読みにくいから @ 使うよ」→むむむ
「もっと他にやることが～」→他のこと「も」やってください。後は優先順位の問題です。

@ つけるかどうかの速度なんて知れてるよ、という話はほとんどの場合は当てはまるでしょう。けれども自分が今書いている処理を extension にすべきかどうかで悩んでいるような人にとっては「速度は重要」です。ライブラリを書いていて、処理が 10000 回るケースなんて、ざらにあります。そしてその処理を extension にすべきかどうかの判断は、保守性も含めて考えると、非常に難しいものです。そういうときに @ を使うべきかどうか知っておくのは、悪いことじゃないはずです。

ちなみに、私の @ 使いどころは入出力が絡むところで、track_errors を On にしてエラーを補足するようにしています。java だと try/catch するポイントですね。