10

たとえば、単純なオブジェクトキャッシングを実装する場合、どちらの方法が高速ですか？

1. return isset($cache[$cls]) ? $cache[$cls] : $cache[$cls] = new $cls;

2. return @$cache[$cls] ?: $cache[$cls] = new $cls;

特に警告/通知が実際に発行されて抑制されている場合は、どこか@で実行するのにかなりの時間がかかります（そしてなぜだろうか）。isset()一方、追加のハッシュルックアップを意味します。では、どちらが優れているのか、そしてその理由は何ですか？

開発サーバーと本番サーバーの両方で、E_NOTICEをグローバルに保持したいと思います。

4

5 に答える 5

8

どちらの方法がより速いかについては心配しません。それがマイクロ最適化です。どちらがより読みやすいコードであり、より優れたコーディング手法であるかについて、私はもっと心配します。

あなたの意図がはるかに明確であるため、私は確かに2番目のオプションよりも最初のオプションを好むでしょう. また、変数を常に明示的にテストして、期待どおりの結果が得られていることを確認することにより、エッジ条件の問題を回避することをお勧めします。たとえば、 に格納されているクラス$cache[$cls]の型が でない場合はどうなる$clsでしょうか。

個人的には、通常、$cache のインデックスが設定解除されるとは思わない場合は、三項演算を使用するのではなく、そこにエラー処理を配置します。そのインデックスが定期的に設定解除されると合理的に期待できる場合は、クラス$clsをシングルトンとして動作させ、コードを次のようにします

return $cls::get_instance();
于 2012-10-04T18:44:08.110 に答える
8

isset()アプローチはより良いです。インデックスが未定義である可能性があることを明示的に示すコードです。エラーを抑えるのはずさんなコーディングです。

この記事10 Performance Tips to Speed Up PHPによると、警告には追加の実行時間がかかり、@オペレーターは「高価」であると主張しています。

事前に警告とエラーをクリーンアップすると、コストのかかる @ エラー抑制を使用できなくなります。

さらに、@カスタム エラー ハンドラに関するエラーは抑制されません。

http://www.php.net/manual/en/language.operators.errorcontrol.php

set_error_handler() でカスタム エラー ハンドラー関数を設定した場合、それは引き続き呼び出されますが、このカスタム エラー ハンドラーは error_reporting() を呼び出すことができます (また呼び出す必要があります)。 .

track_errors 機能が有効になっている場合、式によって生成されたエラー メッセージは変数 $php_errormsg に保存されます。この変数はエラーが発生するたびに上書きされるため、使用する場合は早めに確認してください。

于 2012-10-04T18:46:00.697 に答える
7

@一時的にerror_reporting状態が変化するため、時間がかかると言われています。

特定の値を期待する場合、それを検証するために最初に行うことは、それが定義されていることを確認することです。通知がある場合は、おそらく何かが不足している可能性があります。私の意見では、使用isset()は良い習慣です。

于 2012-10-04T18:44:44.820 に答える
3

さまざまな長さのハッシュ キーを使用し、ハッシュ テーブルのさまざまなヒット/ミス比を使用して、さらにE_NOTICE.

結果は次のとおりです。バリアントを使用するとerror_reporting(E_ALL)、isset()バリアントよりも@約 20 ～ 30% 高速でした。使用するプラットフォーム: OS X 10.8 上のコマンド ライン PHP 5.4.7。

ただし、error_reporting(E_ALL & ~E_NOTICE)短いハッシュ キーの場合は 1 ～ 2% 以内、長いハッシュ キー (16 文字) の場合は 10% の差がありました。

最初のバリアントは 2 つのハッシュ テーブル ルックアップを実行するのに対し、with のバリアント@は 1 回のルックアップしか実行しないことに注意してください。

したがって、@すべてのシナリオで劣っており、最適化する計画があるかどうか疑問に思っています。

于 2012-10-04T22:53:02.550 に答える
1

ここで優先順位が少し混乱していると思います。

まず第一に、より高速な実際のテストを取得したい場合は、負荷テストを行います。述べたように、抑制はおそらく遅くなります。

ここでの問題は、通常のコードにパフォーマンスの問題がある場合、適切な実行とエラー チェックを妨げるのではなく、ハードウェアをアップグレードするか、コードのグランド ロジックを最適化する必要があることです。

速度向上のほんの一部を盗むためにエラーを抑制しても、長期的には何のメリットもありません。特に、このエラーが何度も発生し続け、エラーが検出されて修正された場合よりもアプリの実行が遅くなる可能性があると思われる場合.

于 2012-10-04T19:14:13.643 に答える