7

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:

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?

2 Answers 2

7

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
  • Thanks. But you are saying it's still the fault of plugins? How do I find routines that would cause loading of language files? Is it the language files specific to plugins or wordpress itself? I checked and caller_get_posts isn't used. If a plugin is responsible, wouldn't its initializing routines be added to this grind function list (by xdebug)?
    – He Shiming
    Commented Apr 28, 2013 at 17:59
  • I run xdebug profiling of my WordPress now (23.1.2021) and it is still a problem, much of the time is spent loading .mo files, even without plugins.
    – Lovor
    Commented Jan 23, 2021 at 8:44
0

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.

2
  • What would you recommend as the persistence object cache plugin to work with your performance pack?
    – He Shiming
    Commented Feb 26, 2014 at 2:46
  • Depends on your hosting environment. I've tested it with EM Object Caches file cache and APC Object Cache. W3 Total Cache also features an object cache. All should work, but file or DB based caches won't give as much performance improvement as others. (BTW: If you post question regarding WPPP in the plugin support forum on wordpress.org chances are higher for a quick reply as I don't log into StackExchange often)
    – Björn
    Commented Feb 26, 2014 at 12:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.