Re: [phpGroupWare-developers] Proposal for method of using application-related translation

[Dave Hall]

On Sun, 2008-02-10 at 18:02 +0100, Sigurd Nes wrote:
> Dave Hall wrote:
> > On Sat, 2008-02-09 at 17:04 +0100, Sigurd Nes wrote:
> > I spent some time today benchmarking the 2 versions of code using my
> > ReSight working copying (which is mostly up to date).
> > 
> > The test involved creating an array of the unique strings to be
> > translated from property and calendar's menu classes.  This resulted in
> > 87 strings to be translated.  The test was executed 500 times each, with
> > a 1 second wait between page refreshes.  There was no header or navbar
> > loaded and only the time spent processing the translations was measured.
> > It was run with and without shm.  
> > 
> > The figures below are average execution times.
> > 
> > $only_common version of the code
> > without shm: 0.01280 sec
> > with shm:    0.01143 sec
> > 
> > $appname version of the code
> > without shm: 0.01720 sec
> > with shm:    0.01394 sec
> > 
> > The figures above show that using the only_common check is faster.
> > 
> > Given that the translation code is probably the most used part of the
> > API in any script execution, it should be highly optimised.  In the
> > initial menu load, this can easily be called 200 times.  In most pages
> > it would be called 20 to 50 times - sometimes more.
> > 
> 
> Thanks for taking the time for looking into the code.

No problem.  I had looked at it in detail last week when you proposed
it :)  It wasn't until yesterday I had time to do the benchmarks.

> A bit disappointing that the shm didn't perform much better.

It was run using my laptop as the client and server - which isn't a
normal environment, but it wasn't using any swap, so that doesn't really
explain the lack of performance boost.  There is still some benefit from
shm, but a lot less with the only_common implementation.

A few hundred milliseconds doesn't seem like much, but if we can keep
shaving them off our execution time, that means the same server can
serve more clients with no other changes.  Given the cost of a decent 2U
brand name server starts at around 2kUSD, that can be a significant
saving for our users.

> 
> The menu is supposed to be loaded only once per session - right?

Yes, but the caching is currently disabled as we are still firmly in a
development phase.  Later in the development cycle the caching will be
on by default.  We also need a way of invalidating cached data for users
other than the current user.  This is something I am working on fixing,
there are quite a few options available.

> How about having one super-quick, speed-optimized function for the
> normal translations - and one slightly slower for the rare occasions
> (some apps during menuload) that would need translations related to
> appnames?

I still don't see the need for this.  _If_ there is ever a case where
this becomes a real problem, we can revisit the issue then.  If the long
standing project policies for where translation should go are followed,
this shouldn't be an issue, or will identify it pretty quickly.

To see if this was really going to be a problem, I ran some SQL to see
if there were currently conflicts, and there are, but it seems to be
caused by different spelling / capitalisation / "Anglicising" /
mistranslation of the translated string, not a totally different
translation.

Here is the SQL
SELECT l1.*, l2.app_name, l2.content 
FROM phpgw_lang AS l1, phpgw_lang AS l2
WHERE l1.message_id = l2.message_id
        AND l1.lang = l2.lang AND l1.content != l2.content
        AND l1.app_name = 'common' 
ORDER BY l1.lang, l1.message_id

I also think that having a function which is 90% the same as something
which does the job perfectly well but slower does nothing except
increase load times.

Fixing a few lang files doesn't take very long in the scheme of things.

Cheers

Dave