Skip_english_translation and peformance

yehster wrote on Thursday, February 02, 2012:

The translations.inc.php has an option $GLOBALS.
Is there a place in the Administration page to set this?
The reason why I ask, is when I hard code this to true, I get about a 40-50% performance boost on my calendar page (time drops from 3.1 seconds to 1.4-1.6).
This is with just one user and no concurrency, so I suspect that the performance impact on a live system might be even more significant.
-Kevin Yeh
kevin.y@integralemr.com

bradymiller wrote on Thursday, February 02, 2012:

Hi,

A bit of history here is that there was a time when the Translations were much less efficient (a translation query would go through every translation entry with each xl() function call) and when the table hit about 10000 definitions, there were obvious slow downs. This is when that global was mainly created as I recall. Then the sql keys were modified to only look through 20 or so entries for each xl() call (actually is equal to the number of languages in the table), and things became much faster.

An issue with this global is that I think there is a significant number of English users that actually use the Administration->Language module to translate English labels to other labels (for example, if want to change Encounters label to Visit). Also note it only turns off the translations if English is set; still translates if another language is set.

That being said, would be nice to have a clear way to turn it off completely that doesn’t confuse users.

-brady

yehster wrote on Thursday, February 02, 2012:

Brady,
I think that a lot of this performance gain by skipping translations may be related to the processing power that the audit log takes.  It might be the case that modifying xl() so that when it queries the database it explicitly avoids the audit log, a similar performance boost may be possible with translations fully enabled. 
Further analysis is required.

bradymiller wrote on Thursday, February 02, 2012:

Hi Kevin,
That sounds like a very good idea. So, could just run the query through another sqlStatment type wrapper that uses ExecuteNoLog($statement) instead.
-Brady