Bug 1315660 - Multidomain translations slow hammer down
Summary: Multidomain translations slow hammer down
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Hammer
Version: 6.0.4
Hardware: Unspecified
OS: Unspecified
unspecified
medium vote
Target Milestone: Unspecified
Assignee: Tomas Strachota
QA Contact: Peter Ondrejka
URL: http://projects.theforeman.org/issues...
Whiteboard:
Depends On: 1370562
Blocks: 1122810
TreeView+ depends on / blocked
 
Reported: 2016-03-08 11:31 UTC by Tomas Strachota
Modified: 2019-04-01 20:27 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-02-21 16:54:37 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Foreman Issue Tracker 14092 None None None 2016-04-22 16:35:44 UTC

Description Tomas Strachota 2016-03-08 11:31:57 UTC
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:
<pre>
time hammer --version > /dev/null
real	0m1.584s
user	0m1.453s
sys	0m0.130s

</pre>

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

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 11:31:59 UTC
Created from redmine issue http://projects.theforeman.org/issues/14092

Comment 2 Tomas Strachota 2016-03-08 11:32:03 UTC
Upstream bug assigned to tstrachota@redhat.com

Comment 4 Bryan Kearney 2016-08-16 16:13:11 UTC
Moving to POST since upstream bug http://projects.theforeman.org/issues/14092 has been closed

Comment 8 Bryan Kearney 2017-09-07 19:31:33 UTC
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
tfm-rubygem-fast_gettext-1.4.1-1.el7sat.noarch
[vagrant@sat63-qa-rhel7 ~]$ yum install rubygem-f

Comment 9 Tomas Strachota 2017-09-15 11:40:29 UTC
Yes, anything higher than 1.2.0 is fine, so we should be good with 
tfm-rubygem-fast_gettext-1.4.1-1.el7sat.noarch

Comment 11 Peter Ondrejka 2017-12-19 09:25:40 UTC
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 16:54:37 UTC
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.