Bug 1315660 - Multidomain translations slow hammer down
Multidomain translations slow hammer down
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Hammer (Show other bugs)
Unspecified Unspecified
unspecified Severity medium (vote)
: GA
: --
Assigned To: Tomas Strachota
Peter Ondrejka
: Triaged
Depends On: 1370562
Blocks: 1122810
  Show dependency treegraph
Reported: 2016-03-08 06:31 EST by Tomas Strachota
Modified: 2018-02-21 11:54 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2018-02-21 11:54:37 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Foreman Issue Tracker 14092 None None None 2016-04-22 12:35 EDT

  None (edit)
Description Tomas Strachota 2016-03-08 06:31:57 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:

 * hammer_cli_foreman
 * hammer_cli_foreman_bootdisk
 * hammer_cli_foreman_discovery
 * hammer_cli_foreman_docker
 * hammer_cli_gutterball
 * hammer_cli_import
 * hammer_cli_katello

Standard hammer configuration on ruby 1.9.3:
time hammer --version > /dev/null
real	0m1.584s
user	0m1.453s
sys	0m0.130s


With only one translation domain:
time hammer --help > /dev/null
real	0m1.109s
user	0m1.017s
sys	0m0.092s

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.
Comment 1 Tomas Strachota 2016-03-08 06:31:59 EST
Created from redmine issue http://projects.theforeman.org/issues/14092
Comment 2 Tomas Strachota 2016-03-08 06:32:03 EST
Upstream bug assigned to tstrachota@redhat.com
Comment 4 Bryan Kearney 2016-08-16 12:13:11 EDT
Moving to POST since upstream bug http://projects.theforeman.org/issues/14092 has been closed
Comment 8 Bryan Kearney 2017-09-07 15:31:33 EDT
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
Comment 9 Tomas Strachota 2017-09-15 07:40:29 EDT
Yes, anything higher than 1.2.0 is fine, so we should be good with 
Comment 11 Peter Ondrejka 2017-12-19 04:25:40 EST
Discussed offline with Tomas, verified the presence of tfm-rubygem-fast_gettext-1.4.1-1.el7sat.noarch in Sat 6.3 snap 29
Comment 12 pm-sat@redhat.com 2018-02-21 11:54:37 EST
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA.
> > 
> > For information on the advisory, and where to find the updated files, follow the link below.
> > 
> > If the solution does not work for you, open a new bug report.
> > 
> > https://access.redhat.com/errata/RHSA-2018:0336

Note You need to log in before you can comment on or make changes to this bug.