Priority queue: try once setting #60460
Closed
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
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
ellatrix
requested review from
fullofcaffeine,
youknowriad,
oandregal and
jsnajdr
youknowriad
reviewed
Apr 4, 2024
| for ( let i = firstItems.length; i < list.length; i += step ) { | ||
| asyncQueue.add( {}, () => { | ||
| flushSync( () => { |
There was a problem hiding this comment.
I think it could be fine to keep this regardless.
There was a problem hiding this comment.
Fine to keep but probably not needed?
There was a problem hiding this comment.
Otherwise, is there a point to do the config?
There was a problem hiding this comment.
Otherwise, is there a point to do the config?
The idea is that maybe there's remaining time after the first preview rendering but not enough to render the next one, so the "once" force us the priority queue to schedule an update for later, give a decent amount of time for the browser for potential "interactions" that may come during the first rendering or a bit after but before the next "idle callback". The ultimate goal to reduce the lags as much as we can.
|
Size Change: +80 B (0%) Total Size: 1.73 MB
ℹ️ View Unchanged
|
ellatrix
commented
Apr 4, 2024
| @@ -66,7 +69,7 @@ import requestIdleCallback from './request-idle-callback'; | |||
| * | |||
| * @return {WPPriorityQueue} Queue object with `add`, `flush` and `reset` methods. | |||
| */ | |||
| export const createQueue = () => { | |||
There was a problem hiding this comment.
@youknowriad Do you agree with the naming? Should we call it something else? Or make it private?
There was a problem hiding this comment.
The naming is fine by me and also public is fine. Should we pass the option as true for the "Async" component queue?
But I do wonder if it should be a global option like here or an option per callback (on the add function).
There was a problem hiding this comment.
Whoops, reverted a bit too much in 9190404. Added it back.
I think a "global" option makes sense. I can't think of a case where you'd want to use it for some callbacks and not others? If you really need that separation, you could make two queues?
ellatrix
added
[Type] Performance
|
@youknowriad Should we still do this, or close it? |
|
I don't know, I feel like we don't have enough validation about whether this improves things. So maybe we should not do it for now? WDYT |
|
Ok, I agree |
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.
What?
This is an idea from @youknowriad #60425 (comment)
Basically instead of running multiple priority queue callback in one idle callback and checking idle time remaining,
forcing us to render sync, we could try an option to force one callback per idle callback.This would prevent multiple previews sneaking into a single idle callback, theoretically reducing lag.
The question is if the browser actually waits for the async rendering by React until it run the next idle callback. In my testing, it seem to. I wonder if @oandregal tests any regressions from #60425 with this PR.I want to also look in @jsnajdr because he initially fixed async list in #48238 (reported by @fullofcaffeine). We could check if #48085 doesn't regress. In my testing, image patterns still render one by one after searching for them in the inserter.Why?
How?
Testing Instructions
Testing Instructions for Keyboard
Screenshots or screencast