-
Notifications
You must be signed in to change notification settings - Fork 635
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
improve performance of bubbleINfo #15129
Conversation
UI Smoke TestsTest: success. 2 passed, 0 failed. |
I'm trying to understand how these changes improve things - are they similar to this? |
Yes. One part of the slowdown was caused by that. Another was that the bubble UI was rendering collapsed components that were binding to properties without data context. |
using (node.PropertyChangeManager.SetPropsToSuppress(nameof(NodeModel.Infos), nameof(NodeModel.State))) | ||
using (Disposable.Create(() => { node.BlockInfoBubbleUpdates = true; }, () => { node.BlockInfoBubbleUpdates = false; })) |
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.
I haven't refreshed my memory on the PropertyChangeManager
and how it suppresses property-changed events, but my question is are both this and the blockInfoBubbleUpdates
required? How are these different if both ensure the UI updates on the info bubbles happen at the end of the graph execution? In other words, aren't the updates batched for the end of the graph execution already (with the introduction of PropertyChangeManager
?
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.
PropertyChangeManager handles property changes. There are still CollectionChanged events that slip through the cracks. PropertyChangeManager was never adapted to suppress CollectionChanged events (Not sure it can easily)
BlockInfoBubbleUpdates is required for now to block UpdateBubbleContent calls during collection changed events.
There is an event in the NodeViewModel class, NodeModel.Infos.CollectionChanged += () => {UpdateBubbleContent()};
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.
LGTM, did you find a way to measure the performance improvement done by this fix?
@@ -1464,7 +1465,15 @@ private void DisposeErrorBubble() | |||
|
|||
public void UpdateBubbleContent() | |||
{ | |||
if (DynamoViewModel == null) return; | |||
if (NodeModel.BlockInfoBubbleUpdates) |
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.
You can simplify this with:
if (NodeModel.BlockInfoBubbleUpdates == true || DynamoViewModel == null) return;
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.
I find it easier to read this way.
Manually measured. I could not find any reliable automated way to measure UI responsiveness |
using (node.PropertyChangeManager.SetPropsToSuppress(nameof(NodeModel.Infos), nameof(NodeModel.State))) | ||
using (Disposable.Create(() => { node.BlockInfoBubbleUpdates = true; }, () => { node.BlockInfoBubbleUpdates = false; })) |
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.
Probably could have stopped collection notifications on nodeModel.Infos, but a dedicated flag for updates to bubbleInfo seemed easier to do and understand
using (node.PropertyChangeManager.SetPropsToSuppress(nameof(NodeModel.Infos), nameof(NodeModel.State))) | ||
using (Disposable.Create(() => { node.BlockInfoBubbleUpdates = true; }, () => { node.BlockInfoBubbleUpdates = false; })) |
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.
PropertyChangeManager handles property changes. There are still CollectionChanged events that slip through the cracks. PropertyChangeManager was never adapted to suppress CollectionChanged events (Not sure it can easily)
BlockInfoBubbleUpdates is required for now to block UpdateBubbleContent calls during collection changed events.
There is an event in the NodeViewModel class, NodeModel.Infos.CollectionChanged += () => {UpdateBubbleContent()};
@@ -1464,7 +1465,15 @@ private void DisposeErrorBubble() | |||
|
|||
public void UpdateBubbleContent() | |||
{ | |||
if (DynamoViewModel == null) return; | |||
if (NodeModel.BlockInfoBubbleUpdates) |
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.
I find it easier to read this way.
Well... I was asking because I haven't found any reliable way to measure Dynamo graph loading performance, When the performance improvement is of seconds if I use dotTrace I get similar times with/without the fix :( |
https://master-5.jenkins.autodesk.com/job/Dynamo/job/DynamoSelfServe/job/pullRequestValidation/15905 |
DYN-6438 - long time to run Graph when you disconnect a node (i.e when nodes have errors/warnings)
Add “collapsed” visibility for all bubble controls when no data binding exists.
Reduce thread switching and update all node bubbles at the end of graph to xecution
Without fix, Graph Run takes ~ 1 min.
With fix, Graph Run takes ~ 3 seconds.