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

Add task merging for graph updates #4276

Merged
merged 3 commits into from
May 11, 2015
Merged

Add task merging for graph updates #4276

merged 3 commits into from
May 11, 2015

Conversation

lukechurch
Copy link
Collaborator

@Benglin @ikeough Any reason to not do graph update task merging?

wrt: http://adsk-oss.myjetbrains.com/youtrack/issue/MAGN-7078

Opinions solicited.

@lukechurch
Copy link
Collaborator Author

(The automated testing for this is a bit more complicated - at this stage what I want to understand is: is there any reason that we can't follow this strategy?)

@ikeough
Copy link
Contributor

ikeough commented Apr 20, 2015

This was what I tested, and it seemed to work well. I think merging update graph tasks can only be a good thing. The only time the scheduler gets flooded with update requests is when someone is sliding a slider. And the desired behavior during slider sliding is that graph updates feel as immediate as possible. So this makes that possible. And, because rendering is tied to update (we render some amount of stuff every time we update), and because rendering is more expensive than update in many cases, it is to everyone's benefit to render less - that is, to update less.

@@ -33,11 +33,11 @@ internal override TaskPriority Priority

internal UpdateGraphAsyncTask(IScheduler scheduler, bool verboseLogging1) : base(scheduler)
{
verboseLogging = verboseLogging;
this.verboseLogging = verboseLogging1;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've just updated this in master and RC0.8.0_ds branches.

@Benglin
Copy link
Contributor

Benglin commented Apr 20, 2015

Hi @ikeough, @lukechurch, an UpdateGraphAsyncTask keeps the GraphSyncData for a bunch of nodes that are currently marked as modified at the time UpdateGraphAsyncTask.Initialize method is called. Consider a case where NodeA is updated before NodeB, and both these node changes result in two instances of UpdateGraphAsyncTask objects in the pipeline, the modification on NodeA will be discarded.

If we really do want to decide if either of the tasks should be kept, then we need to implement a strategy that meaningfully compares the tasks. For a start, I think storing IEnumerable<System.Guid> in each of the UpdateGraphAsyncTask for the nodes that it is meant to update, then use it for comparison (e.g. SequenceEqual) should be good enough. Let's not store the NodeModel themselves, I'd rather not have UpdateGraphAsyncTask hold more references to NodeModel objects if possible (and System.Guid comparison is quick, too).

Does that make sense?

@Benglin Benglin self-assigned this Apr 20, 2015
@lukechurch
Copy link
Collaborator Author

@Benglin I see.

We could certainly use a comparison based strategy to fix the most common case which is a slider manipulation.

In general it seems that what we need is an API where we can take two tasks and instead of simply comparing them, we can return a new task that replaces both. In this case it would be computing the union of the modified nodes?

@Benglin
Copy link
Contributor

Benglin commented Apr 27, 2015

Oops, sorry @lukechurch I had this open in a browser tab and didn't get back to it before a system restart. To fix the slider case, adding a list of System.Guid would help for now (as outlined in my comment above). Task merging by taking a union requires a scheduler to be tweaked and I personally do not think that justifies the problem it solves. If you would still prefer to have task merging, then perhaps we can have a chat about it and get that implemented, too. Thanks again for fixing this!

@lukechurch
Copy link
Collaborator Author

@Benglin np, thanks for the input PTAL at these changes which I think address the concern


// They're different, keep both
return TaskMergeInstruction.KeepBoth;
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the update, @lukechurch, this looks great! :)

Another minor thing is, as @ke-yu pointed out, HashSet.IsSupersetOf can probably do this better but for graph nodes (which are not in huge numbers) this should be fine. LGTM!

Sorry for being late on the review anyway.

lukechurch added a commit that referenced this pull request May 11, 2015
Add task merging for graph updates
@lukechurch lukechurch merged commit 04fea98 into master May 11, 2015
@Benglin Benglin deleted the lukechurch_magn7078 branch May 12, 2015 05:38
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.

3 participants