[wp-hackers] Fix that translated WordPress takes 86% longer to start
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%)
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
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
- 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?
More information about the wp-hackers