Tag: Speed

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

These horses are somehow not cool. Speeding up your blog is.

I am working on a WordPress project that has a pretty heavy database, and I want to be able to auto-optimize the WordPress database. Even though they are integrating this functionality into WordPress 3.0, I want it now, and without having to use a plugin (I have had some issues with WP-DBManager configuring properly on a few sites).

Imagine waiting 18 seconds for a page to load (on a high-speed connection) — not just the home page, but any inside page of a website. Pretty frustrating, right? Having bad load times makes a huge difference to your customers. I helped a new client reduce page load time from 19 seconds to 3 seconds.

I’ve tried repairing the permissions. Limiting desktop icons. Removing Safari’s support for ICO icons. Clearing more hard drive space. Nothing. Frickin’. Worked. I have been so frustrated by how slow my Mac Pro has been. I have 2 2.66GHz dual-core processors, 2 GB of memory, and still I was getting spinning beach balls, crunching hard drives and slow menus…and nothing seemed to fix it. I decided to take action. I was fed up! And you know what? It’s really quite simple.