POMO library performance considerations

[wet]

Profiling a localized WordPress instance with WPLANG defined as 'de_DE' on my testbed shows that loading the .PO files for WP core and TwentyTen increases the frontend runtime by about 45 percent and the backend runtime by about 30 percent.

This is the profiling environment:

• WordPress 3.2-bleeding r17633
• TwentyTen 1.1
• No active Plugins
• Idling webserver on localhost
• Apache 2.2.9
• PHP 5.2.6
• MySQL 5.0.67
• Xdebug 2.1.1
• webgrind 1.1
• Windows 7 SP1

Without WPLANG defined, runtimes for various code paths are as follows:

• Front page with 10 simple posts: 2300 ms
• Admin Dashboard: 3000 ms
• RSS XML feed output: 1130 ms

With the de_DE l10n in effect, runtimes increase as such:

• Front page with 10 simple posts: 4300 ms
• Admin Dashboard: 4280 ms
• RSS XML feed output: 2950 ms

I wonder whether anyone is able to reproduce this grave performance degradation. A sample output from webgrind showing various POMO functions as the top offenders is attached.

Webgrind profiling report of site frontpage

Replace is_null() with NULL comparison. A low hanging fruit, but 1.5 percent performance increase is maybe better that a sharp stick in the eye. See  http://hakre.wordpress.com/2011/03/29/php-is_null-vs-null/.

Looks like a fine candidate for 3.2.

Also see #17268, there is a patch which reduces the used php-memory for translation about 75%.

Nothing here yet, punting.

pomo-entry-17637.patch seems like a valid patch.

Refreshed as per coding standards.

I observed the same issue.

Please correct me if I am wrong, but it looks like every internationalized strings are loaded on every page. Loading the complete mo file on every page could explain such huge difference of performance between English and localized versions. Moreover, as WordPress is growing, the mo file is growing too (for de_DE.mo, it was 296 ko for 2.8, 386 ko for 3.0 and 435 ko now), so this performance issue is growing too.

So if my assumption is good, the most optimized solution could be to load only the strings needed for the current page. I am not a specialist of the pomo structure, but I imagine that in the worst case it could mean splitting the current mo file in many small files. Obviously it would be difficult to do and maintain.

However, it may be a good solution to split the current mo file in two. One small file for the frontend and the big file for the admin side (it seems to me that there are not a lot of core strings displayed on the frontend). Maybe it would be necessary to load both files on the admin side. I am not sure.

This way, of course, we do not improve the time running on the admin side but we should improve a lot the time running on the frontend. Since, inn most cases, the frontend is loaded much more times than the admin, the server load decrease should be quite perceptible...

@Chouby: Splitting the translation files in two is an idea worth exploring, but you should open a new ticket for it.

There are also many strings which can be seen only in multisite version. Maybe they should get right textdomain? Or is there any reason why these strings are not inluded in existing separate multisite .mo file?

Replying to pavelevap:

Or is there any reason why these strings are not inluded in existing separate multisite .mo file?

I guess this also should be investigated in a new ticket.

OK, there are 2 new tickets: #19831 #19832

FWIW, I've experienced similar performance issues as outlined in the original report on an Ubuntu 10.04 LTS (PHP 5.3.2, APC 3.1.3) system running Wordpress 3.3.1.

Switching from Wordpress' own gettext implementation to PHP's native gettext libary (using a patch from #17268) improved page response times by 43% compared to a stock Wordpress 3.3.1 installation where WPLANG is used.

Feature	Response time	Performance hit
Stock 3.3.1, WPLANG not set	139ms	0%
WPLANG set to 'sv_SE'	255ms	45% slower
WPLANG set + patch from #17268	145ms	4% slower