Hi Felix,
thanks for your input!
Felix J. Ogris schrieb:
> Oliver Tappe ([EMAIL PROTECTED]) wrote:
>
> [...]
>
>> Solution 1 is (slightly) easier to read, but it is slower and requires more
>> memory, since it copies the hash with the existing translations into a new
>> hash. This copying does not scale well if there are a lot of translation
>> modules being loaded (each one copies the hash, which is getting bigger and
>> bigger).
>
> [...]
>
>> Benchmarking has shown that solution 2 is in fact unusable for many modules,
>> as the copying of the hash becomes very slow. Solutions 1 and 3 scale ok
>> (i.e.
>> O(n)) but solution 1 is still twice as fast as solution 3 (as the creation of
>> the temporary hash that is being passed into the method costs time).
>
> Hi,
>
> did you swap solution 1 for solution 2 in the above passage? Solution 1
> ought to be slow, whereas #2 doesn't copy any hashes...?
Yep, sorry about that :-/
> I'd like to propose another solution:
>
> 4.
> sub Data {
> my $Self = shift;
> my $Language = $Self->{Translation};
>
> return if ref $Language ne 'HASH';
>
> $Language->{green} = 'grün';
> $Language->{yellow} = 'gelb';
> $Language->{Being blue is not a lot of fun}
> = 'Blau sein macht im Deutschen schon mehr Spaß';
>
> return 1;
> }
Yep, surely better than 3 :-) I would prefer renaming $Language to
$Translation though, for improved clarity.
>
>> Now that I have looked at the code in Kernel::Language, I wonder if we should
>> not try to find a way to limit the loading of Language modules to the ones
>> which are actually being used by the current HTTP-request.
>> Please correct me if I'm wrong (and I hope I am), but as far as I can see, we
>> currently load *all* available Language modules in the constructor of
>> Kernel::Language.
>
> Hmm, no, just all modules which match $Self->{UserLanguage}_*.pm.
Ah, you are right of course. I was not precise enough - what I should have
been saying is that OTRS always loads all Language modules matching the
current language. So if the user is currently surfing the FAQ-module in
German, the de_* files for all other modules would be loaded, too, even if
they are not used at all by the current HTTP-request.
Then again, the exact performance penalty of this is unclear, especially since
many modules provide an icon on the toplevel which will cause that modules
language files to be loaded anyway.
I suppose in the long run it would be best to keep the translations in a
persistent cache, such that they would only be loaded once, not once per
request. Implementing this should not be a problem with Apache & ModPerl, but
I wonder whether this is possible with IIS?
Ah well, something to tinker with on long, boring days ;-)
> If you use
> mod_perl for Apache, loading some unused modules shouldn't have that
> performance impact, I guess (Yes, I know, OTRS doesn't run on Apache only).
The actual .pm-loading is cached by ModPerl, but not the invocation of Data(),
so the copying of the translation still takes place for every request - or am
I missing something?
cheers,
Oliver
_______________________________________________
OTRS mailing list: dev - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/dev
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev
