Skip to content
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

Merged
merged 2 commits into from
Apr 22, 2024
Merged

improve performance of bubbleINfo #15129

merged 2 commits into from
Apr 22, 2024

Conversation

pinzart90
Copy link
Contributor

@pinzart90 pinzart90 commented Apr 15, 2024

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.

Copy link

github-actions bot commented Apr 15, 2024

UI Smoke Tests

Test: success. 2 passed, 0 failed.
TestComplete Test Result
Workflow Run: UI Smoke Tests
Check: UI Smoke Tests - net8.0

@mjkkirschner
Copy link
Member

I'm trying to understand how these changes improve things - are they similar to this?
https://github.com/DynamoDS/Dynamo/wiki/Dynamo-UI-Performance#wpf-dispatcher-issues

@pinzart90
Copy link
Contributor Author

pinzart90 commented Apr 15, 2024

I'm trying to understand how these changes improve things - are they similar to this?
https://github.com/DynamoDS/Dynamo/wiki/Dynamo-UI-Performance#wpf-dispatcher-issues

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; }))
Copy link
Contributor

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?

Copy link
Contributor Author

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()};

Copy link
Contributor

@RobertGlobant20 RobertGlobant20 left a 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)
Copy link
Contributor

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;

Copy link
Contributor Author

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.

@pinzart90
Copy link
Contributor Author

LGTM, did you find a way to measure the performance improvement done by this fix?

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; }))
Copy link
Contributor Author

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; }))
Copy link
Contributor Author

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)
Copy link
Contributor Author

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.

@RobertGlobant20
Copy link
Contributor

LGTM, did you find a way to measure the performance improvement done by this fix?

Manually measured. I could not find any reliable automated way to measure UI responsiveness

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 :(

@pinzart90
Copy link
Contributor Author

https://master-5.jenkins.autodesk.com/job/Dynamo/job/DynamoSelfServe/job/pullRequestValidation/15905
Only one failure, as in master (the remove PII test)

@pinzart90 pinzart90 merged commit a127282 into master Apr 22, 2024
22 of 23 checks passed
@pinzart90 pinzart90 deleted the bubble_performance_Fix branch April 22, 2024 14:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants