[wp-hackers] Fix that translated WordPress takes 86% longer to start

[Heiko Rabe]

I think, that solution 2 and 3 are not possible, because:

2.) Most provider doesn't allow mod_php and only provide CGI based php 
processing.
In this case you have no chance to cache it as you think.

3.) very bad in multi-lingual environments. Some of my friends and i too 
are running backends with at least 3 languages simultanously.
The languages can be switched or defined by the current user (author or 
admins) at any time. Also multi-lingual frontend blogs need
the ability to switch easy the language. This won't be possible by hard 
replacement at php files!

Remaining is only your first option: split the file. But this may only 
suitable for plugins or themes, where you could separate the backend 
part (huge) from the frontend part (small).
The WordPress language file itself will be used 99.9% in backend only, i 
don't find any advantage to split it.

If you think a plus of 90 msec is huge, please look at the timings of 
database requests of some so called premium or magazin themes, that run 
upto 400 queries to produce a page.
They are the time killer, also all of the plugins filtering the whole 
content again and again. Queries and cascaded content filter (using 
expensive regexp) will consume much more time.
The only time aspect of loading language files is doing ajax. In case of 
ajax calls, that don't require any translation, all tranlation file load 
could be dropped.
For this only case i would delay loading (only store file names and 
textdomains but not load them) in case of DOING_AJAX and introduce a 
function   
    require_ajax_translations()  
that load by calling in Ajax case the translation. This would safe 
indeed time processing ajax calls, all other cases are in my opinion no 
subject of change.

Heiko Rabe
> Hi,
>
> I've been looking at the startup time of WordPress.
>
> The translation startup cost (gettext_reader->load_tables()) is
> really, really expensive.
>
> Average loadtime of clean 1 post 2.7.1 startpage: 0.102s
> Average loadtime with translation: 0.190s (+86%)
>
> Hmm. :)
>
> Solution 1: split .mo file in two by separating admin stuff from the rest
> Solution 2: cache i10n object (in this case using APC)
>
> Average loadtime solution 1: 0,127s (+25%)
> Average loadtime solution 2: 0,126s (+24%)
> Average loadtime solution 1+2: 0,122s (+20%)
>
> "Solution" 3: translate all strings directly in the php files Lots of
> trouble (with updates and so on) to get to those last 20ms. Not for
> general consumption.
>
> 2 is possible to implement with a plugin by adding a filter to
> load_textdomain(). If noone tells me its a bad idea :) I'll add a trac
> item and see what happens.
>
> Splitting the mo file and handling the result can be done with a
> plugin already. I don't however really see a reason why it isn't the
> standard setup:
> - it takes back much of the cost of translation
> - it makes the i10n object ~300k smaller (for each thread/process)
> - the split can easily be scripted
>
> One could argue that the default themes and the akismet plugin
> translations should be split out too.
>
> What are the reasons not to do it? Has this been discussed before?
>
> / Johan
> _______________________________________________
>
>