Oliver Tappe (ot@otrs.com) 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