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

Johan Eenfeldt johan.eenfeldt at gmail.com
Thu Feb 19 20:47:29 GMT 2009


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

More information about the wp-hackers mailing list