-
Notifications
You must be signed in to change notification settings - Fork 356
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
Do not let angular parse the treeview data as it can be 🐢 HUGE 🐌 #5729
Conversation
@@ -1,10 +1,12 @@ | |||
- return if @display == 'generic_objects' || @display == 'main' | |||
= miq_accordion_panel(_("Generic Object Classes"), true, "god") do | |||
:javascript | |||
ManageIQ.tree.data['#{tree.name}'] = #{tree.locals_for_render[:bs_tree]}; |
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.
Ugh, GOD is special, there's no tree
, only @tree
.
(and that's the only issue I'm seeing 👍)
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.
Oh GOD WHYYY 😢 I'll fix it
2ba59f4
to
02a4883
Compare
Checked commit skateman@02a4883 with ruby 2.3.3, rubocop 0.69.0, haml-lint 0.20.0, and yamllint 1.10.0 |
Tested both in GO and in other explorers, LGTM :) |
Do not let angular parse the treeview data as it can be 🐢 HUGE 🐌 (cherry picked from commit 6d088fe) https://bugzilla.redhat.com/show_bug.cgi?id=1727443
Hammer backport details:
|
I did some profiling around the TreeView with 5 thousand nodes and I realized that the bottleneck is in Angular and not the TreeView code. I asked @himdel about the problem and we realized that this was caused by a bugfix that started sending the tree data as an object instead of a string. The object is being parsed by angular and if it is 5MB, well 🐢 🐌 happens.
The solution is to get the data into the component in an alternative way, so preventing Angular from unnecessarily parsing it. Ideally this could be solved by having separate (UI-)API endpoints for trees, but we're not there yet. So our solution was to utilize the
ManageIQ.trees
global object by temporarily saving the data into it until the component gets a reference.After this change the performance increase is significant, the bottleneck now is in the rendering which is totally fine. We can't really make the browser faster 😉
Before:
After:
@miq-bot add_reviewer @martinpovolny
@miq-bot add_reviewer @himdel
@miq-bot add_label performance, bug, trees, hammer/yes
https://bugzilla.redhat.com/show_bug.cgi?id=1703556