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...?
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;
}
> 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. 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).
Regards,
Felix
_______________________________________________
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
