18

私は最近、いくつかの PHP の作業を行っています。私が見たすべてのコードでは、人々はほとんどメソッドを使用しない傾向があります。(変数もほとんど使用しない傾向がありますが、それは別の問題です。)これがなぜなのか疑問に思っていたところ、「1つのパラメーターと空の関数本体を含む関数呼び出しは、7-8 $を実行するのとほぼ同じ時間localvar++ 操作. 同様のメソッド呼び出しは、もちろん約 15 の $localvar++ 操作です" here .

PHP ページがコンパイルされてキャッシュされた場合でも、これは本当ですか? 効率化のためにメソッドの使用をできるだけ避けるべきですか? コード ブロックが繰り返される場合は常に、メソッドを使用して、よく整理された人間が判読できるコードを作成するのが好きです。メソッドなしでフラットなコードを書く必要がある場合、メソッド本体を「インライン化」するプログラムはありますか? そうすれば、素敵なコードを書いて、展開する前にそれを醜くすることができます.

ちなみに、私が見てきたコードは Joomla 1.5 コアといくつかの WordPress プラグインのものなので、彼らは何をしているのかを知っている人だと思います。

注:誰もがこの質問に飛びついて、一般的な最適化について話したことを嬉しく思いますが、実際には、インタープリター言語での最適化について話しているのです。PHP について話しているという事実の少なくともいくつかのヒントは素晴らしいでしょう。

4

16 に答える 16

75

どのくらいの「効率」が必要ですか?あなたも測定しましたか?時期尚早の最適化は諸悪の根源であり、測定を伴わない最適化は常に時期尚早です。

Optimization Clubのルールも覚えておいてください。

  1. 最適化クラブの最初のルールは、最適化しないことです。
  2. 最適化クラブの 2 つ目のルールは、測定せずに最適化しないことです。
  3. アプリが基になるトランスポート プロトコルよりも高速に実行されている場合、最適化は終了しています。
  4. 一度に 1 つの要因。
  5. マーケットロイドもマーケットロイドのスケジュールもありません。
  6. 必要な限り、テストは続行されます。
  7. これが Optimization Club での最初の夜である場合は、テスト ケースを作成する必要があります。
于 2008-10-09T14:53:13.483 に答える
57

Joomla と Wordpress は、優れたPHP コードの最大の例ではありません。私はそれに取り組んでいる人々に対して個人的なことは何もありません。人々がウェブサイト/ブログを持てるようにする方法は素晴らしいです。多くの人々が自由時間をすべてこれらのプロジェクトのいずれかに費やしていることを私は知っていますが、コードの品質はかなり悪いです (悪気はない)。

信じられない場合は、過去 1 年間のセキュリティに関する発表を確認してください。また、2 つのいずれかからパフォーマンスを探していると仮定すると、それらのコードはそこでも優れていません。したがって、これは決して良いコードではありませんが、Wordpress と Joomla はどちらもフロントエンドで優れています。非常に使いやすく、人々は Web サイトを取得して何かを実行できます

そして、それが彼らが成功している理由であり、人々はコードの品質に基づいてそれらを選択するのではなく、彼らが何を可能にしたかで選択します.

パフォーマンスに関する質問に答えると、はい、すべての優れた機能 (関数、クラスなど) がアプリケーションの速度を低下させるのは事実です。したがって、アプリケーション/スクリプトがすべて1つのファイルに含まれていると思います。その場合は、悪い PHP コードを自由に記述してください。

コードを拡張して複製を開始したらすぐに、保守可能なコードを作成することによる (速度の) トレードオフを検討する必要があります。:-)

IMHO このトレードオフは、次の 2 つの理由からかなり小さいものです。

  1. CPU安い。
  2. 開発者は安くはありません。

今から 6 か月後にコードに戻る必要がある場合、そのナノ秒がコードの実行を節約できたかどうかを考えてみてください。厄介なバグを修正する必要がある場合は、さらに加算されます (コードが重複しているため、3 ~ 4 回)。

PHP の実行を高速化するために、さまざまなことができます。一般に、 APCなどのキャッシュが推奨されます。APCは本当に素晴らしいです。バックグラウンドであらゆる種類の最適化を実行します。たとえば、PHP ファイルのバイトコードをキャッシュし、データを保存するための関数をユーザーランドに提供します。

たとえば、そのスクリプトを実行するたびに構成ファイルを解析する場合、ディスク I/O は非常に重要です。シンプルなapc_store()apc_fetch()を使用すると、解析済みの構成ファイルをファイルベースまたはメモリベース (RAM) のキャッシュに保存し、キャッシュが期限切れになるか削除されるまでそこから取得できます。

もちろん、キャッシュは APC だけではありません。

于 2008-10-09T17:53:27.003 に答える
21

次の質問への回答が表示されます:開発者は読みやすさまたはパフォーマンスを最初に目指すべきですか?

コンセンサスを要約すると: 特定の領域でパフォーマンスに対処する必要があるという事実を (テスト/プロファイリングを通じて) 知っていない限り、読みやすさははるかに重要です。

于 2008-10-09T14:52:53.983 に答える
9

99% のケースで、コードの理解可能性について心配する必要があります。テスト、理解、保守が容易なコードを記述します。

パフォーマンスが非常に重要な少数のケースでは、PHP などのスクリプト言語は最良の選択ではありません。結局のところ、PHP の多くのベース ライブラリ関数が C で記述されているのには理由があります。

于 2008-10-09T14:54:03.683 に答える
8

個人的には、関数呼び出しのオーバーヘッドが発生する可能性がありますが、コードを 1 回 (パラメーター化して) 記述し、それを 85 か所で使用することを意味する場合、1 か所で修正できるため、はるかに先を行っています。

スクリプト言語は、コーディングの際に考慮すべき基準は「十分」と「機能する」だけであるという考えを人々に与える傾向があります。

于 2008-10-09T14:54:06.773 に答える
5

特にPHPのような高速インタプリタでは、読みやすさ/保守性の欠如が、それから得られる(または得られない)効率に値することはないと思います。

そしてWordPressについてのメモ:私はWordPressコードをたくさん閲覧しました。それらの人々が良いコードについて何も知っていると思い込まないでください。

于 2008-10-09T18:03:57.527 に答える
4

最初の質問に答えるには、はい、それは真実であり、コンパイルされたオペコードにも当てはまります。はい、コードの重複のためにコードが大きくなりすぎるという極端な場合を除いて、関数呼び出しを回避することでコードを高速化できます。

「コードブロックが繰り返されるところならどこでも、メソッドを使用して、よく整理された人間が読めるコードを書くのが好きです」と好きなことをしてください。

すべての関数呼び出しを削除するというこの恐ろしい残虐行為をコミットする場合は、少なくともプロファイラーを使用し、重要なコードの 10% に対してのみ実行してください。

于 2008-10-09T15:53:55.967 に答える
3

マイクロ最適化がマクロの速度低下につながる例:

関数を手動でインライン化することを真剣に検討している場合は、ループを手動で展開することを検討してください。

JMPは高価であり、展開してループを排除し、すべての条件付きブロックを排除できれば、CPUのキャッシュを探すだけで無駄になる時間をすべて排除できます。

データベースから物事を引き出すのと同様に、実行時の変数の拡張も遅いので、そのすべてのデータをコードにインライン化する必要があります。

実際、コードを実行してユーザーにメモリをコピーするためにインタプリタをロードするのは非常に無駄です。可能なすべてのページを事前に計算し、各ページをメモリに保存して、すぐに使用できるようにしてください。 ?確かにそれは速いです!

ああ、今、私たちはインターネットと呼ばれる遅いものを私たちの間に持っています。それはユーザーエクスペリエンスを妨げ、使用できるコンテンツの量を制限しています。事前にページを事前に計算し、それらをすべてアーカイブして実行するのはどうですか。ユーザーローカルマシン?それは本当に速いでしょう!

しかし、それはCPUサイクルを浪費することになります。それらの多くは、ページの読み込み時間やブラウザーコンテンツのレンダリングなどで、仲介者をスキップして、印刷されたメディアでページを配信するだけです。天才!。

/ meは、10年間(手作業で)事前計算を行い、誰も見たくないページを印刷している間、会社が崩壊するのを監視しています。

これはあなたにはばかげているように聞こえるかもしれませんが、私たちの他の人にとっては、あなたが提案したことはそれだけばかげています。

最適化は良いのですが、適切な場所に線を引いてください。そうすれば、コードベースを維持できないようなくだらないコードベースを持っているために、睡眠中にあなたを追跡するコードに取り組んでいる将来の人々について心配する必要はありません。

注:はい、私はgentooを使用しています。どのように推測しましたか?

于 2008-10-09T17:40:58.043 に答える
2

もちろん、悪い PHP コードを書くべきではありません。しかし、何か悪いことを書いたら、いつでも言い訳としてパフォーマンスを使うことができます:-)

于 2008-10-09T14:58:05.657 に答える
2

これは時期尚早の最適化です。関数呼び出しはローカル整数変数を増やすよりもコストがかかる (ほぼすべてのコストが高くなる) というステートメントは真実ですが、関数呼び出しのコストはデータベース クエリに比べて依然として非常に低くなります。

以下も参照してください。

ウィキペディア -> 最適化 -> いつ最適化するか

c2.com Wiki -> 時期尚早の最適化

于 2008-10-09T15:03:00.547 に答える
1

PHP の主な強みは、機能するアプリをすばやく簡単に作成できることです。その強みは、ルーズな (悪い) コードを記述しても、ある程度期待どおりに動作させることができることにあります。

いくつかの CPU サイクルを節約する必要がある場合は、PHP を使用すべきではありません。PHP Web アプリのパフォーマンスが低い場合、コード実行の速度ではなく、非効率的なクエリが原因である可能性がはるかに高くなります。

于 2008-10-09T15:41:28.750 に答える
1

効率性についてあらゆる点で心配しているなら、一体なぜスクリプト言語を使用しているのですか? はるかに高速な言語 (お気に入りのコンパイル済み言語をここに挿入) でプログラミングする必要があります。その結果、おそらくコードはより多くなり、読みにくくなりますが、非常に高速に実行され、ベスト コーディング プラクティスを目指すことができます。

真剣に、実行速度のためにコーディングしているのであれば、PHP をまったく使用すべきではありません。

于 2008-10-09T16:28:03.633 に答える
0

MVCアーキテクチャパターンを使用してWebアプリケーションを開発する場合は、キャッシュとシリアル化から大きなメリットを得ることができます。ビューまたはその一部をキャッシュしたり、モデルをシリアル化したりできます。

経験から、モデルは表示されているデータのほとんどを解析して生成することがよくあります。RSSフィードを解析するモデルのように、特定のモデルが新しいデータを頻繁に生成しないことがわかっている場合は、解析したすべてのデータをどこかに詰め込んで、時々更新することができます。

于 2008-12-07T03:53:02.590 に答える
0

10 分の例をいくつか書き、プロファイラーで実行します。

どちらがミリ秒単位で速いかがわかります。

プロファイラーをお持ちでない場合は、ここに投稿してください。PHPEd プロファイラーで実行します。

時間差があるとすれば、その多くは、クラスが保存されているファイルを開く必要があることに起因すると思われますが、それもテストする必要があります。

次に、スパゲッティ コードを維持しなければならないことに対して、数ミリ秒を気にするかどうか自問してみてください。ユーザーのいずれかが気付くでしょうか?

編集

プロファイラーは大量のトラフィックをシミュレートしませんが、1 人のユーザーにとってどの方法がより高速であるか、およびコードのどの部分がどれだけの時間を使用しているかがわかります。特に、繰り返し実行される操作をプロファイリングする場合は、ループごとに 1000 回とします。

多くの人が使用する高速なコードは、多くの人が使用する低速のコードよりも高速であると (常にではありませんが) 想定できます。

于 2009-10-09T22:30:16.600 に答える
0

コードのマイクロ最適化について講義する人は、一般に、プロファイリングについて聞いたことがないため、1 ページあたり 50 個の SQL クエリを持ち、合計 2 秒かかる人たちと同じです。しかし、彼らのコードは最適化されています!!! (そして地獄のように遅い)

事実 : 別の Web サーバーを追加することは難しくありません。データベースを複製することです。DB に負荷がかかる場合、ウェブサーバーのコードを最適化することは、最終的な損失になる可能性があります。

注 : SQL を含む単純なページ (フォーラム トピックなど) の 2 ~ 3 ミリ秒は、PHP Web サイトの適切なターゲットです。私の古いウェブサイトはそうしていました。

于 2009-10-22T09:15:39.810 に答える
0

wordpress の php コードを見ると、html の間に php タグが混ざり合っており、頭の中でスパゲッティにつながっています。

ただし、Phpbb3 はその点で優れています。たとえば、テンプレート エンジンによって解析される、{template} タグを含む xhtml 形式のファイルである、php 部分とスタイル部分の間に厳密な区分があります。どちらがはるかにきれいです。

于 2009-04-27T08:45:12.520 に答える