Drupal is distributed in English by default. Translations into other languages require downloading the translation, enabling the locale module and importing the translation's .po file.

Another use for the locale module is when the Drupal terminology is not suitable for the site's audience, and the site owner wants to replace end user facing text with custom versions of that. In this case, they create a locale, and change the strings they want.

However, the locale module has some inherent performance overhead, since it has to lookup the translated/replaced strings from the database.

The strings overrides module was written to solve this issue: when you only need to change a few strings in a site, and not have a whole translation. The module stores the translation strings in the variable table, which is cached for every page load, trading possibly many database lookups for some memory overhead.

A client recently contacted us for a performance tuning consultation, and incidentally, they had done things the usual way: created a new locale, added a few strings to change the user interface facing text.

Locale overhead was not their main problem, but we got to do some real life benchmarking on locale vs. string overrides.

The client had only 45 strings that they changed. So, using the import feature in the latest version of string overrides, we exported the custom translation using locale, and imported it in string overrides.

Using a busy page, and restarting MySQL between tests to nullify the effect of the query cache, we got the following figures:


# of Queries Database Time (ms) Total Time (ms)
Locale 625 205.32 440.41
String Override 619 197.49 420.89


The gain is a modest 6 less queries, and about 20 ms gain in total page generation time, i.e. 4.5% improvement.

The serialized data in the variable table for the 45 strings takes 6220 bytes.

The above figures may not be representative for your own web site, and before you decide to use one approach over the other, it is recommended that you measure with your specific data set size.

Comments

Mon, 2008/05/19 - 17:40

Hi Khalid,

It looks like the difference is minimalistic. Is this on Drupal 5 or Drupal 6? I believe it should be less queries in the Drupal 6 version, as the call to variable_get is stuck right within the t() function.

Thanks,

Rob

Is your Drupal or Backdrop CMS site slow?
Is it suffering from server resources shortages?
Is it experiencing outages?
Contact us for Drupal or Backdrop CMS Performance Optimization and Tuning Consulting