Red Hat Bugzilla – Bug 1315660
Multidomain translations slow hammer down
Last modified: 2017-11-10 09:10:43 EST
When hammer is installed with multiple plugins the startup slows down. Profiling showed we're loosing quite some time in fast-gettext's initialisation and translation methods. It loads all available .mo files for all languages in all plugins regardless what language is used. Another inefficiency lies in multidomain translations we're using (one domain per plugin). For each translation fast-gettext iterates over all domains until it finds the key.
Simple measurement for hammer with plugins:
Standard hammer configuration on ruby 1.9.3:
time hammer --version > /dev/null
With only one translation domain:
time hammer --help > /dev/null
The solution seems to be to create custom fast-gettext translation repository that would merge the keys at load time to get rid of the search loops in each translation. Loading the .mo files lazily might also improve the performance.
Created from redmine issue http://projects.theforeman.org/issues/14092
Upstream bug assigned to email@example.com
Moving to POST since upstream bug http://projects.theforeman.org/issues/14092 has been closed
I see this as delivered but not installed. Tomas..is the tfm version good enough?
================================================= N/S matched: fast_gettext =================================================
rubygem-fast_gettext.noarch : A simple, fast, memory-efficient and threadsafe implementation of GetText
tfm-rubygem-fast_gettext.noarch : A simple, fast, memory-efficient and threadsafe implementation of GetText
Name and summary matches only, use "search all" for everything.
[vagrant@sat63-qa-rhel7 ~]$ rpm -qa | grep fast_gettext
[vagrant@sat63-qa-rhel7 ~]$ yum install rubygem-f
Yes, anything higher than 1.2.0 is fine, so we should be good with