[Scheduler] Profiler Features (second try) #16542
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ebook#16392)" This reverts commit 4ba1412.
|
React: size: 🔺+0.4%, gzip: 🔺+0.3% Details of bundled changes.Comparing: 8a01b50...24b1b26 react
scheduler
Generated by 🚫 dangerJS |
|
Regarding "suspended" event. I'm not sure if it's supposed to mean any time the loop stops. Or if it's supposed to mean that work loop stopped but there's more work to do later. |
This currently breaks tests.
Their definitions used to be more fuzzy. For example, Suspend didn't always fire on exit, and sometimes fired when we did _not_ exit (such as at task enqueue). I chatted to Boone, and he's saying treating Suspend and Resume as strictly exiting and entering the loop is fine for their use case.
gaearon
force-pushed
the
profiling-revert-revert
branch
from
40130ba
to
1f5f7df
Compare
|
This is ready for review. Production bundle diff: https://gist.github.com/gaearon/b3ee8dadf9d4fac5f407dfa9e3c247fc/revisions |
gaearon
commented
Aug 22, 2019
gaearon
commented
Aug 22, 2019
aweary
reviewed
Aug 22, 2019
sebmarkbage
reviewed
Aug 22, 2019
sebmarkbage
reviewed
Aug 22, 2019
sebmarkbage
reviewed
Aug 22, 2019
sebmarkbage
reviewed
Aug 22, 2019
This reverts commit 9c30b0b. Unnecessary because GCC
gaearon
commented
Aug 22, 2019
| : null; | ||
|
|
||
| const profilingState = | ||
| enableProfiling && sharedProfilingBuffer !== null |
There was a problem hiding this comment.
Keeping this sharedProfilingBuffer !== null check because while new Int32Array(null) would work, IE9 which doesn't have ArrayBuffer also doesn't have Int32Array.
sebmarkbage
reviewed
Aug 22, 2019
| if (currentTask === peek(taskQueue)) { | ||
| pop(taskQueue); | ||
| } | ||
| if (enableProfiling) { |
There was a problem hiding this comment.
I figured you'd fork the finally too but I guess this works too.
sebmarkbage
approved these changes
Aug 22, 2019
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a revert of a revert of #16145 + my attempts to fix its issues.
You need to read individual commits.
The main fix has already landed independently in #16407.
However, there were a few more issues in #16145 that I'm fixing in this PR:
There is a bigger conceptual issue though that I'm struggling with.
(Feel free to skip these details)
#16145 added a bunch of
pop()calls — for example, when a task errors or get cancelled. My understanding is that this was done as an optimization. I.e. we don't need to schedule another loop if there's no actual tasks in the loop left.That optimization doesn't seem like it would cover all cases. For example, if we have tasks [A, B, C], and then cancel C, B, and A in sequence, only A would be popped (because it's the first item). So this optimization seems "optional" and not something we can rely on.
However, the tests do rely on this optimization being present.
Without it, the "main thread" bar never stops:
I don't know how to interpret this.
Is this optimization essential for profiler's correctness? In that case it seems dodgy that depending on the order in which you cancel callbacks, it would either work or not.
Or is this optimization purely an optimization? Are the test asserting on implementation details too aggressive? Why does the "Main Thread" bar never stop? Or are we missing a "suspended" event that should have happened in that case?
Finally, the logic to determine whether we "suspended" or "resumed" seems fragile to me. I don't know for sure what those terms are supposed to mean. For example, if a callback errors, did we "suspend"? It seems like no from the code, but I don't know why. Conceptually, I'd think of an "error" as "suspending" the scheduler loop. Unless "suspend" means something else here.
My last commit just removes the "optimization" (9a64404). It breaks some tests but I can't move further without understanding their intent. Is it the code, the assertions, or the test setup that needs to change?
Was this more than an optimization? I'll leave it at that so someone else can pick it up. :-)
I chatted to Boone, and arrived at a solution that satisfies both of us. Basically, I wasn't sure what Suspended and Resumed events mean. Boone told me it's okay to treat them as "exit the loop" and "enter the loop".
So in the next commits I did the following:
pop()optimization that affected non-profiling paths to reduce the risk. (9a64404)