New locale with performance reduction

I have to set up a bunch of drupal sites within the next month. So in the moment I am testing the actual cvs/pre-4.5. version to find out what is the best solution. The recent download provides a new locale module (PO files upload etc.) with some improvements.

I am not happy to report that the new locale results in a tremendous performance reduction especially with older and slower servers.
The speed reduction (devel) is between 800% (slower server & small percentage of transl. strings) and more than 2000% (faster server & a biger amount aof transl. strings) compared to a setting with locale disabled or english as default.

Drupal with new locale "adds" more speed reduction to faster machines than to slow server - relative to settings with locale disabled ord english selected. This looks like a sort of compensation: One can take away more power from the powerful, because enough strength remains; one cannot take away too much power from the less powerful because of the apparent weakness (this is not a competent technical explanation)

Values are page execution time (ms) provided by devel, start page was called

SERVER 1: 2x Intel(R) Xeon(TM) CPU 3.06GHz, 2 GB mem, 3 SCSI 76GB, RAID 5, Freebsd 4.10, Apache/2.0.50, PHP/4.3.8 
SERVER 2: 1x AMD Athlon(tm) XP 1700+, 1 GB mem, 1 IDE HD 60 GB, Apache/1.3.31, PHP/4.3.8
SERVER 3: 2x Pentium II Xeon/400Mhz, 512 MB mem, 1 SCSI  4GB + 1 SCSI 8 GB, Freebsd 4.10, Apache/2.0.50, PHP/4.3.8

SERVER                                SERV 1    SERV 2    SERV 3
locale disabled	                      43	  70	  548
locale + english	                      46	   75	  572
locale + german/147 (7% transl)	    756	  858	  5055
locale + german/248 (12% transl)	    791	  881	  5236
locale + german/1058 (51% transl)	    975	  1068	  6300

see chart at : http://www.univie.ac.at/elearn/exec_engl.pdf

Also there is a speed reduction if using a bigger amount of translated strings. Going fom 7 % to 51 % translated strings results:

SERVER 1:  almost 30 % slower (than with a smaller amount of transl. strings)
SERVER 2: almost 25 % slower
SERVER 3: almost 25 % slower

Comparing an older cvs-version (end of May) with a new locale version (on the same server - fastest) result in a performance difference too

SERVER (fastest)     SERVER1 (new locale)    SERVER 1 (former locale)
locale disabled	         43                    82
locale + english	        46                     91
locale + german           756                    93

Installing turck-mmcache (PHP cache: http://drupal.org/book/view/2604 ) helps a little bit the slowest server with biggest amount of transl. string (5% faster), but helps more with locale disabled or english default (60% faster than without turck-mmcache):

SERVER (slowest)                        SERV 3      SERV 3 + turck-mmcache
locale disabled	                      548	      222
locale + english	                     572         236
locale + german/1058 (51% transl)	    6300       6026

Conclusions

If other drupal testers confirm these results and there is no solution to bring back drupal's good performance with new locale module enabled and translations uploaded, it should be taken into account to provide the former locale module as alternative setup (with instructions how to use it instead of new locale together with 4.5). this is important especially for older and slower servers.

While the speed reduction will not be noticed by a user if a fast server is used (though measurably slower than without translation and than older version) it will be noticed if served by slower and older servers (the "old server" in this test is a 1998 DELL with 2 Pentium II XEON, 512MB, and SCSI HD!), because the reduction results in 'experienced' awkward delay (2-4 Sec).

Also it should be recommended to produce selective translations and upload small portions of translated strings (also the new locale should provide a functionality to search/download portions of strings for translating). Uploading the complete PO file with all translations seems very time consuming even with fast connections.

But first I hope the performance problem can be solved and will be a temporary phenomenon.

univie