-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Dispatcher helper optimizations #3119
Dispatcher helper optimizations #3119
Conversation
Thanks Sergio0694 for opening a Pull Request! The reviewers will test the PR and highlight if there is any conflict or changes required. If the PR is approved we will proceed to merge the pull request 🙌 |
@Sergio0694 did a few things just shuffle around in the order of the file, saw some signature changes, but just wanted to quickly check the public API surface was all the same in the end? Happy to change it, but we'd need to move to the 7.0 dev branch for anything that breaks the API. I'll look at this more closely a bit later, was just taking a quick peak first. |
@michael-hawker I didn't make any signature changes actually (or I would've marked the PR as being a breaking change), I just reordered the methods to be more structured. The previous order they were using in the file was just making it harder to follow the program flow I think. The only real change in this PR is the improved efficiency by skipping the dispatcher scheduling when the invoking thread is the same one and already has UI thread access 😄 |
Thanks @Sergio0694, I went through commit-by-commit, thanks for separating the re-order as it's own commit :) Would it be good for us to add some Unit Tests to these functions? |
Fwiw, this can be a break change depending on how the developer has written their apps. It's making what was an asynchronous call now essentially synchronous, which is changing the order things are executed in which can lead to a lot of unintended - and potentially difficult to track down - side effects. Give the default Dispatcher.RunAsync will always reschedule and not run immediately it is probably safer to stick with that default behaviour, and potentially add another method to DispatcherHelper that checks first. |
@JohnnyWestlake Ah, yeah that's fair. I guess what I meant by "no breaking changes" was the fact that the current behavior was entirely non deterministic (since dispatched callbacks could be scheduled at any point in time that's not known in advance), so that shouldn't have been something developers would be relying upon. And by that rationale, changing that so that some calls might sometimes be invoked synchronously, would make no difference, conceptually - it'd still be some point in time after the method is invoked, and in some cases that point in time would just end up happening a tiny bit sooner. That said, I understand your point. If you'd like me to separate those methods through a different API (though I'd argue that'd make the API surface a bit crowded and possibly harder to understand for consumers), do you have a name for that in mind? 🤔 |
@Sergio0694 this is a cool addition to these helpers. I agree with @JohnnyWestlake that while the API is the same, changing this behavior could adversely effect some potential code-paths (unknowingly). I think it'd be good to call out as a perf improvement, but with a note for developers using it as a 'breaking change' (for behavior) in our 7.0 release first. Would you mind rebasing this change on top of the dev/7.0.0 branch and potentially adding some Unit Tests in general for these dispatchers to help us protect their functionality (and you new additions) in the future? |
9d510f0
to
1cebda0
Compare
This PR has been marked as "needs attention 👋" and awaiting a response from the team. |
@michael-hawker Since we've moved this PR to 7.0, I might as well throw in a couple other ideas:
Let me know what you think! 😊 |
@Sergio0694 those are some interesting discussion points. For the naming there's a CoreDispatcher.RunAsync method, so I believe we were trying to differentiate it from that, would something like @vgromfeld @azchohfi thoughts on optimizing this a bit since we're calling it a breaking change anyway? |
@michael-hawker I think that
If nothing else, I feel like having those methods using the same name would actually make them feel more "integrated" into the native APIs, which could also increase the discoverability for eg. developers just getting started on UWP (which in that case wouldn't be using the overload with the explicit dispatching priority anyway) so that'd be nice 😄 EDIT: on second thought, I'll do you one better, personally I'd rename all the methods in the |
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.
Alex and I figured it makes sense to merge this PR as is now, and we can open another issue later if we want to rename them before the 7.0 release. |
This PR is part of the group being tracked in #3108.
PR Type
What kind of change does this PR introduce?
What is the current behavior?
Currently, APIs in the
DispatcherHelper
class will always result in a callback dispatch on the targetCoreDispatcher
instance, and aTask
orTask<T>
allocation, even when the caller is already running on that sameCoreDispatcher
instance, therefore not needing the dispatching at all.What is the new behavior?
There are just 2 changes being introduced by this PR:
Action
orFunc<T>
on the UI thread, if the targetCoreDispatcher
already has thread access, the delegates will be invoked directly, skipping the dispatcher scheduling entirely.Action
on the same UI thread,Task.CompletedTask
is used, to avoid the unnecessary allocation of a newTask
instance every time.PR Checklist
Please check if your PR fulfills the following requirements: