-
Notifications
You must be signed in to change notification settings - Fork 898
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use nested hashes instead of string keys #17357
Use nested hashes instead of string keys #17357
Conversation
This avoids needing to generate a new string value for each key on setting of the value and retrieving, and the extra hashes are not a huge consumer of space. Of note, the keys are now not strings at all. Top level will be the class names, and the child keys will be just the raw IDs. The @ems_xml_nodes value is not used anywhere besides the lookup that was changed in this commit, so the change of this structure should not have an adverse affect... hopefully...
60aaf40
to
ef73d6e
Compare
Checked commit NickLaMuro@ef73d6e with ruby 2.3.3, rubocop 0.52.1, haml-lint 0.20.0, and yamllint 1.10.0 |
@miq-bot assign @gmcculloug |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@NickLaMuro - This looks good to me.
@miq-bot add_label fine/yes, gaprindashvili/yes |
…st_workflow Use nested hashes instead of string keys (cherry picked from commit 5f22e97) https://bugzilla.redhat.com/show_bug.cgi?id=1593798
Fine backport details:
|
…st_workflow Use nested hashes instead of string keys (cherry picked from commit 5f22e97) https://bugzilla.redhat.com/show_bug.cgi?id=1593797
Gaprindashvili backport details:
|
For both instantiating the values, and retrieving the data, using string based keys requires a bunch of new object allocations for something that is simply used for a faster lookup for data already put into the XML structure (I think...), by using a nested hash structure, we can keep the same "lookup" functionality, but not require the extra allocations to do so.
As far as I can tell, the only place this lookup is used is in one method, so this should be okay to change.
Benchmarks
The benchmark script used here basically runs the following:
And is targeting a fairly large EMS, with about 600 hosts.
Note: The benchmarks for this change do NOT include the changes from other PRs (#17354 for example). Benchmarks of all changes can be found here.
Links