Testing Translation Function Speeds in WordPress

After reading Pippin Williamson’s post about gettext speed issues, I wanted to learn more. My IDX+ plugin has 815 translatable strings, and I was worried that it was having a performance impact on the plugin.

I created a test that looped through different methods of outputting and printing strings to try and determine their relative speed. WordPress uses different functions for translating strings, as documented in the Codex, and I included __() and _e(), the functions I use the most often.

Here are the results of a 100,000-iteration loop:

• echo 'Test': 0.1786 seconds
• $out .= 'Test': 0.2454 seconds (37.4% slower)
• __('Test'): 0.5301 seconds (196.8% slower)
• _e('Test'): 0.5639 seconds (215.7% slower)
• echo __('Test'): 0.5722 seconds (220.4% slower)
• __('Test', 'test'): 0.5743 seconds (221.6% slower)
• _e('Test', 'test'): 0.6076 seconds (240.2% slower)
• echo __('Test', 'test'): 0.614 seconds (243.8% slower)
• $out .= __('Test', 'test'): 0.6885 seconds (285.5% slower)

“Findings” (non-scientific)

• Contrary to what I had read, echoing inline was by far the fastest method.
• Adding a domain (the second parameter) to translation functions slows the functions down a bit.
• Storing strings in a variable after using __() is slow.
• All times are well below 1/10th of a second when translating 10,000 strings instead of 100,000.

Conclusion

Although translating 100,000 strings adds half a second processing time, if your site is processing well less than that, you shouldn’t have a problem.

It seems the site Pippin was working on had enough strings to affect the responsiveness of the site, but I would bet that’s not a normal site. I also would bet that the issues the site was having are not because of the translation functions themselves, but the translation plugin the site was running.

I’m going to be using more _e() and less echo __(), but other than that