Bug 5269 - Performance optimization: create single optimized translation cache
Performance optimization: create single optimized translation cache
Status: NEW
Product: OJS
Classification: Unclassified
Component: Localization
3.1
PC Windows XP
: P3 normal
Assigned To: PKP Support
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-03-26 22:30 PDT by jerico
Modified: 2013-05-29 16:19 PDT (History)
2 users (show)

See Also:
Version Reported In:
Also Affects: OCS 2.3.4, OHS 2.3.2, OMP 1.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description jerico 2010-03-26 22:30:42 PDT
Profiling shows that up to 30% overall request execution time is spent in the Locale::translate() method.

Reasons are:
- highly fragmented translation files (and translation cache files)
- loop over all translation files for each translation key (including full cache timeout check with only that causing 5 file/inode accesses per file and translation key!)

Proposed improvements:
- build a single cache of all translation keys
- enable in-memory caching for translation keys
- do cache timeout check with a single inode access (current system time - mtime) and only once per request
Comment 1 Alec Smecher 2010-03-31 09:30:49 PDT
Florian, I've also been toying around with the idea of namespacing for translation keys. This would help keep everything organized more logically, too. That way, we could map a prefix to a particular file rather than searching through them all sequentially.
Comment 2 jerico 2010-06-19 17:31:52 PDT
Translation should be based on a performance optimized and proven technology like the gettext library. Translation strings could probably quite easily be translated into .po/.mo files for release. AFAIK gettext is much faster than alternative I18N solutions from Zend or PEAR. As gettext is based on the same "message id" or "message key" principle as our translation system it might be easy to use it internally. A bit of thought needs to be invested for string replacement. Gettext has of course very flexible mechanisms in place for that but they differ a bit from our approach.