web-dev-qa-db-ja.com

パフォーマンスを向上させるためにWordPressをクリーンアップしますか？

現在のWordPressコードベースを見てみると、関数が過剰に使用されていることは明らかです。私のカウントは8100以上の関数/メソッドはWordPressコードベースの中で定義されています。それはひどい、そしてひどい資源の使い方です。

多くの関数（またはクラス）の問題は、wordpressがDRYではないことを意味します（自分で繰り返さないでください）。これらのブロックの多くを組み合わせたり置き換えたりできると確信しています。より良いパターンで

ただし、「インターフェース」を緩やかに変更せずにバックエンドコードの結合を開始できるように、現在のAPI（これらすべての関数）をバッファリングする必要があります。

ソリューション？

PHP 5と6にはSPLクラスの自動ロードがあります。ロードする前にクラスが必要になるまでPHPが待機できるようにする機能です。未使用の機能/ファイルは必要になるまでロードされないため、これ は無駄なリソース を防ぎます。

残念ながら、WordPressはこれを使用できません。PHPの "autoloading"はクラスに対してのみ機能し、WordPressは関数の山だからです。

私はWordPressコードベースをクリーンアップするためのオプションと課題を検討しています、そしてこれは最も大きいようです。

WordPressはプラグイン/テーマ開発者のために（クラスを公開するのではなく）非常に多くの関数を作成しているので、何千ものテーマとプラグインを壊さずにこの深い穴から抜け出す方法はないようです。

私が思いつくことができた唯一のアイデアは、すべての機能を調べてそれらをクラスに変換するスクリプトを書くことです。その代わりに、クラス関数を使った関数と呼ばれるシェル関数が残されていました。

このようなもの：

function wp_foo_bar() {
    call_user_func_array(array('foo' => __FUNCTION__), func_get_args());
}

他の誰かがWordPressコードベースをクリーンアップしようとしましたか？このアプローチに他の問題はありますか？

Clarifyにアップデート

自動ロードを使用するようにシステムを変換することは、コア機能の一部をより優れた設計に移行するときに、リソースのロード方法を制御してファサードを設定するための最初のステップです。関数を減価償却するのははるかに困難です。したがって、この質問はシステムの書き換えの開始から始まります。

ここでやめた場合 - 同じ数の関数があるためにパフォーマンスが大幅に低下する可能性があります - そして今、クラスもオートロードされ始めています。

したがって、これは手続き型コード対OOPとは関係ありません。システム全体の変更に対してAPIをバッファリングするための最良の方法です。現在のワードプレスの開発チームはすでに非常に遅いペースでこれを行っています。ワードプレスシステムにはすでに60を超えるクラスがあります。

phpfunctionscore-modificationscustomization
6
Xeoncross

あなたは、そのようなものがパフォーマンスを向上させるという、非常に大きな仮定に基づいて行動しています。ネタバレ - いいえ、そうではありません。

ロードプロセスは、非常に大まかに言ってで構成されています。

  1. 定義を検索するためのコード（自動ロードまたはカスタム）を任意で実行する。
  2. ファイルを解析するか、オペコードキャッシュから結果を取得します。
  3. 結果を読み込みます。

「自動ロードが速い」はよく知られている誤謬です。最初の自動ロードはusefulです。実際には処理を遅くすることができますファイルの処理はopcodeキャッシュによって大幅に改善されていますが、繰り返しlocatingこれらのファイル（ステップ1）はこれまでのところ最適化されているだけであり、非常に高速に追加されます。

WordPressコアは、より良い編成とクラスの自動ロードから恩恵を受けますか？確かに、PHPのその機能を使用しないことを前提に開発されているため、それは起こりません。

しかし、関数を自動ロードクラスに「変換する」のでしょうか。私の教育を受けた人は、これがパフォーマンスにとって破滅的なものになると思いますが、最初の段階でボトルネックにならないプロセスの一部を最適化しようとします（現在のコアコード/ロード状態）。

13
Rarst

機能的に解釈されたコードは常にOOPより速いでしょう。比較する

function hello_mark() {
  echo 'hello mark';
}

hello_mark();

と

class mark {
  function say_hi() {
    echo 'hello mark';
  }
}

$m = new mark();
$m->say_hi();

解釈と実行のほうが速いのは明らかだと思います。

人々はOOPをしないのは速いので、彼らはそれが "問題領域"をより良く表し、そしてコードの保守をより簡単にするのでそれをします。

コードは、より良いインタプリタを常に使うことができるように、あるいはマシンコードにコンパイルすることができるように、またはFacebookのヒップホップのようにあなたがサポートしている言語の機能を減らして統合することができるようにあなたのインタプリタにウェブサーバ。

特にワードプレスにとって、サイトのスピードに最も影響を与えるのは、使用されているキャッシュの品質です。 phpコードを改善しても、オブジェクトキャッシングを利用するのと同じパフォーマンス向上は得られません。

とにかく、遅延ロードされていない関数がたくさんあるからといって、遅延ロードが実行されていてもwordpressが初期化を完了するまでにロードされないという意味ではありません。ソフトウェアの論理構造を壊さないときはいつでも初期化に必要ではない関数を自分のファイルに置くことができるほど十分に良い言語を知っていることをコア開発者にある程度の信用を与えなさい。初期化中にdelete_optionが呼び出されないため、update_optionはdelete_optionとは別のファイルにあります。

9
Mark Kaplun

幸運を祈りますが、これによってパフォーマンスが向上することはありません。

WordPressは、時間の経過とともに、段階的な変化を伴って、ますますオブジェクト指向になっています。過去4年間の更新ごとに、主要なコードの一部がよりクラス指向の設計にリファクタリングされています。

それにもかかわらず、OOや自動ロードなど、このようなことは本質的に「速い」というわけでも、実際に「良い」というわけでもありません。でも心配しないで、これは一般的な誤りです。

一般にOOPは、プログラミングにおける別の編成方法です。多くの場合、より安全でクリーンなアプローチです。しかし、それは本質的に「より良い」というわけではなく、実際にはほとんどすべての現実的なシナリオにおいて、著しく低速でメモリ集約型です。 a）保守とコードテストがより簡単であること、b） "正しい"方法として多くの学校で教えられていること、c）プログラマが人々のようなものであることから、OOPモデルが一般的に好まれます。物事のモデルを構築するのが好きです。 OOPはその「モデル」の考え方によく合っています。 1つのコードで「もの」を表現してから、自分の「もの」を他の「もの」と相互作用させて、レゴの各部分を合わせることができます。きちんとした、きれいな、きちんとした:)

真実は、オペコードキャッシングのようなものでは、自動ロードは実質的にスピード上の利点を提供せず、組織上の利点のみを提供します。誤解しないでください。利益は利益であり、優れた組織は良いことです。しかし、自動化されたプロセスではなく、ものを整理することでより良い組織化を実現します。

すべてのコードをクラスに移動して、それらのクラスに関数を単なるフックにするコードを書くことはできますか？もちろんです。それは何に役立ちますか？実体はありません。

あなたの具体的な欲求に取り組むために：

関数を減価償却するのははるかに困難です。したがって、この質問はシステムの書き換えの開始から始まります。

まず、私はあなたが「非推奨」を意味したと思います。

第二に、あなたは一度に全部を書き直してあなたの目標を達成することはできません。それが私の大事な点です。戻って3.1または3.2を見てください。それでは4.0を見てください。クラスの数と、それらが時間の経過とともに実際にリファクタリングされる方法に注意してください。

実際にそのプロセスで改善するのでない限り、作業コードを書き換えて同じ結果を得るためだけに多くの時間を費やすことは意味がありません。 WordPressの各部分が改良されるにつれて、通常はクラス/ OOPシステムに変更されます。漸進的な進化時間の経過とともに変化し、古いプラグインを無効にし、それをサポートして修正するなどのために新しいコードを作成できるようにします。あなたは一夜で世界を破ることはできず、みんなが従うことを期待して、あなたは物事をゆっくりそして系統的に変えなければなりません。

7
Otto

@Xeoncross、

WP Devプロファイルに書き込みます

私のアプリの中で可能な限り最高の最適化を目指して努力しているので、私の質問の中には特定の問題の中心に深く突き当たるものがあることに気付くかもしれません。

それは、App、あなたのApp、またはあなたが取り組んでいるAppにとっては、すべてうまくいきました。あるいはあなた自身のプログラミング哲学とテクニック。

しかし、Wordpressはコミュニティであり、そのため動作は異なります。小規模または個々のプロジェクトで優先されるプログラミング構造、言語、および効率性の観点から、（より良いWordがないために）事柄を犠牲にする可能性があります。

しかしWordpressはコミュニティであることの結果として多くを得ます。エコシステムは大きく、多様で、開発は進んでいきます。そして結果として、あるいはそれにもかかわらず、WordPressは非常に人気があります。

コミュニティとして、Wordpressは個々のプロジェクトや開発者が働くのと同じように振る舞うことを想定できません。

あなたはリンゴとオレンジ、そしてそれらが育つ木とオレンジよりもリンゴが好きな人々を比較しています。

私は自分自身をプログラマとは考えていません。OOP、クラス、手続き、そしてそれ以降の利点とメリットについては議論できません。

1
markratledge