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

[Frank Bueltge]

Thanks Heiko,
i had also write an answer with my bad englsih and now i can delete my
answer.
Im full your opinion and i wish, WordPress give more attention on the
multilingual users and other languges as english.


On Thu, Feb 19, 2009 at 10:11 PM, Heiko Rabe <heiko.rabe at code-styling.de>wrote:

> 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
>> _______________________________________________
>>
>>
>>
>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>