web-dev-qa-db-ja.com

ローカライズされたWordPressはずっと遅いですか？

Xdebugとwebgrindを使ってWordPressのインストールをプロファイルしています。約20のプラグインが有効になっているので、xdebugがボトルネックを見つけることができるだろうと考えました。

しかし、驚いたことに、ローカライズルーチンが実行時間の大部分を占めているようです。そして、私はWordPressのローカライズ版を使っています。単一のAjaxページロードのwebgrindからの次の出力を参照してください。

webgrind output

私のプラグインの中には、実行時間がそれぞれ1％未満であるものがあります（実行時間のパーセンテージで測定）。しかし、翻訳ルーチンTranslation_Entry、MO、POMOは全体の30％以上を使用しています。

これがなぜなのか、そしてローカライズ版の使用を禁止すべきかどうかと思います。それとも、プロファイルのパフォーマンスに間違ったアプローチを使用していますか？

performancelocalization
6
He Shiming

各翻訳ファイルについて、WordPressはそれを解凍しなければなりません、そして各エントリーはTranslation_Entryオブジェクトに変換されます。

短い文字列 "caller_get_posts"は非推奨です。代わりに "ignore_sticky_posts"を使用してください。 翻訳すると3倍のメモリが必要になります。

  '"caller_get_posts" is deprecated. Use "ignore_sticky_posts" instead.' => 
  Translation_Entry::__set_state(array(
     'is_plural' => false,
     'context' => NULL,
     'singular' => '"caller_get_posts" is deprecated. Use "ignore_sticky_posts" instead.',
     'plural' => NULL,
     'translations' => 
    array (
      0 => '"caller_get_posts" ist veraltet. Bitte nutze stattdessen "ignore_sticky_posts".',
    ),
     'translator_comments' => '',
     'extracted_comments' => '',
     'references' => 
    array (
    ),
     'flags' => 
    array (
    ),
  )),

そしてそれが、正しく書かれたプラグインとテーマが無条件に言語ファイルをロードしない理由です。残念ながら、正しく書かれたプラグインやテーマはそれほど多くありません…

WordPressの翻訳は、メモリへの影響を減らすために管理者とフロントエンド部分に分けられます。まだたくさんあります。

あなたはmu-pluginで特定の言語ファイルのロードを防ぐことができます：

add_filter( 'override_load_textdomain', 'stop_language_files', 10, 2 );

function stop_language_files( $bool, $domain )
{
    if ( 'textdomain_you_do_not_want' === $domain )
        return TRUE;

    return $bool;
}
6
fuxia

ローカライズはWordPressにとって大きなパフォーマンスの打撃であり、問​​題はプラグインではなくWordPressのローカライゼーションの実装にあります（ただし、優れた書かれたプラグインは影響を減らすことができます）。 WP Performance Pack Pluginは、理想的にはローカライゼーションの影響をほとんど相殺するさまざまな最適化を特徴としているため、解決策を提供します。

0
Björn