Localized WordPress is much slower?

2 Views

I’m using xdebug and webgrind to profile my WordPress installation because it’s a bit slow. As there are some 20 plugins activated, I figured xdebug will be able to find the bottleneck.

However, to my surprise, it appears that localizing routines are taking the majority part of the execution time. And yes I’m using a localized version of WordPress. Please see the following output from webgrind of a single ajax page load:

Read More

webgrind output

I can see some of my plugins taking less than 1% execution time each (measured in percentage of execution time). But translation routines, Translation_Entry, MO, POMO are using more than 30% of the total.

I’m wondering why this is, and whether I should prevent from using a localized version? Or am I using the wrong approach to profile performance?

Post Views: 2

Related posts

Leave a Reply

2 comments

  1. For each translation file, WordPress has to unpack it, then each entry will be converted into an Translation_Entry object.

    The short string “caller_get_posts” is deprecated. Use “ignore_sticky_posts” instead. will need three times more memory when it is translated:

      '"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 (
    ),
  )),

    And that’s the reason why properly written plugins and themes do not load their language file unconditionally. Unfortunately, there are not many properly written plugins and themes …

    The WordPress translations are split into an admin and a front end part to reduce the memory impact. It is still a lot.

    You can prevent loading of specific language files with an 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;
}

  2. Localization is a big performance hit on WordPress and the problem lies not with plugins but with WordPress’ localization implementation (although good written plugins can reduce the impact). WP Performance Pack Plugin offers a solution as it features different optimizations which ideally almost cancel out the pefrormance impact of localization.