Bug 1315660

Summary:	Multidomain translations slow hammer down
Product:	Red Hat Satellite	Reporter:	Tomas Strachota <tstrachota>
Component:	Hammer	Assignee:	Tomas Strachota <tstrachota>
Status:	CLOSED ERRATA	QA Contact:	Peter Ondrejka <pondrejk>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	6.0.4	CC:	bbuckingham, bkearney, ehelms, rplevka, tstrachota
Target Milestone:	Unspecified	Keywords:	Triaged
Target Release:	Unused
Hardware:	Unspecified
OS:	Unspecified
URL:	http://projects.theforeman.org/issues/14092
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-02-21 16:54:37 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1370562
Bug Blocks:	1122810

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

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 Satellite Program 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