Take the 2-minute tour ×
WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. It's 100% free, no registration required.

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?

share|improve this question
add comment

2 Answers 2

up vote 2 down vote accepted

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;
}
share|improve this answer
    
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 Apr 28 '13 at 17:59
add comment

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.

share|improve this answer
    
What would you recommend as the persistence object cache plugin to work with your performance pack? –  He Shiming Feb 26 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 Feb 26 at 12:36
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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