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

[Johan Eenfeldt]

Hi Heiko,

Thank you for commenting!

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.

Wow, really?

> In this case you have no chance to cache it as you think.

Well, I have it as a plugin (for my own usage if nothing else). As
long as you have mod_php there is some kind of shared memory available
I think.

I agree that it might not be usable for everyone. I'll only be
suggesting a filter in there so I can plug in the thing.

> 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!

I agree. I mentioned it only for completeness.

> 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.

The translation for wp-admin/* as well as some other stuff is not
needed for 99+% of all visits.

It is almost 2/3 of the translation strings, it is expensive, and they
can be included dynamically when needed.

That was the example I used with the numbers listed.

> 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 should fix that! :) (or cache it or something)

Our frontpage (the most common page by far) when created takes ~0.15s
with all plugins and stuff. The translation is quite noticable in that
context.

> 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.

Sure. "the_content" for example is extremely expensive by default.

I sent some mails about that to this list a month or so ago. The most
expensive one was actually the smilies processing (performance much
improved for 2.8 though -- plugin version for earlier versions at
http://wordpress.org/extend/plugins/faster-smilies).

But most of those can be turned of or pre-processed.

> 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

Interesting idea, though it would require modification to any plugin
doing ajax calls that needs translation.

> all other cases are in my opinion no subject of change.

Sure there are other ways to make a site slow down. I just find it
unnecessary to add more if you do not have to.

Thank you,
Johan