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
_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)
- 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
- All times are well below 1/10th of a second when translating 10,000 strings instead of 100,000.
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
You must be logged in to post a comment.