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

perf(virtual-scroll): use auditTime instead of sampleTime #13131

Merged
merged 1 commit into from
Sep 21, 2018
Merged

perf(virtual-scroll): use auditTime instead of sampleTime #13131

merged 1 commit into from
Sep 21, 2018

Conversation

nename0
Copy link
Contributor

@nename0 nename0 commented Sep 14, 2018

The CdkVirtualScrollViewport uses sampleTime to collect multiple scroll events into one until the next animation frame.
However the sampleTime also samples even if there is no new upstream values. Which in this case creates an basically useless requestAnimationFrame callback.
A better choice would be the auditTime operator, which only schedules the requestAnimationFrame when there is actually a new upstream value.
In our case it has the exact same behavior, as from looking at the performance profiler in chrome I found out this: first the scroll event fires, then pending requestAnimationFrame callbacks get called, regardless if they where scheduled in the current or previous frame and then the paint occurs.

@googlebot googlebot added the cla: yes PR author has agreed to Google's Contributor License Agreement label Sep 14, 2018
@mmalerba mmalerba self-assigned this Sep 14, 2018
@mmalerba
Copy link
Contributor

I'll have to take a thorough look at this, I seem to remember intentionally picking sampleTime after comparing them for some reason

@julianobrasil
Copy link
Contributor

@mmalerba, I think you're referring to this #10179 (comment)

@nename0
Copy link
Contributor Author

nename0 commented Sep 15, 2018

Interestingly throttleTime has a config parameter to define, if it emits before (leading) the delay, after (trailing) or both. When you set it to only trailing its equivalent to sampleTime and it might actually be a bit faster as it does not create a timer Observable each time. It did not choose this to keep things simple.

@nename0
Copy link
Contributor Author

nename0 commented Sep 15, 2018

I was wrong. throttleTime with trailing differs from auditTime:

  1. if if there is only one value in a delay it will not emit (possibly a bug throttle and throttleTime broken for single values when trailing is true. ReactiveX/rxjs#2859)
    So in our case auditTime is the best option
  2. it will emit on complete

So in out case the best choice is auditTime.

@mmalerba
Copy link
Contributor

@julianobrasil Thanks, that's what I was thinking of.

@nename0 I agree that auditTime does seem like it would be more efficient here. Let me patch this PR and check the demos, will LGTM if they all seem to work right

@mmalerba mmalerba added pr: lgtm action: merge The PR is ready for merge by the caretaker labels Sep 17, 2018
@ngbot
Copy link

ngbot bot commented Sep 17, 2018

I see that you just added the pr: merge ready label, but the following checks are still failing:
    failure missing required label: "target: *"

If you want your PR to be merged, it has to pass all the CI checks.

If you can't get the PR to a green state due to flakes or broken master, please try rebasing to master and/or restarting the CI job. If that fails and you believe that the issue is not due to your change, please contact the caretaker and ask for help.

@mmalerba mmalerba added the target: patch This PR is targeted for the next patch release label Sep 17, 2018
@mmalerba mmalerba merged commit c26dc74 into angular:master Sep 21, 2018
@nename0
Copy link
Contributor Author

nename0 commented Sep 21, 2018

Thanks!

@nename0 nename0 deleted the fix-virtual-scroll branch September 23, 2018 08:35
roboshoes pushed a commit to roboshoes/material2 that referenced this pull request Oct 23, 2018
)

The `CdkVirtualScrollViewport` uses `sampleTime` to collect multiple scroll events into one until the next animation frame. 
However the `sampleTime` also samples even if there is no new upstream values. Which in this case creates an basically useless requestAnimationFrame callback.
A better choice would be the `auditTime` operator, which only schedules the requestAnimationFrame when there is actually a new upstream value.
In our case it has the exact same behavior, as from looking at the performance profiler in chrome I found out this: first the scroll event fires, then pending requestAnimationFrame callbacks get called, regardless if they where scheduled in the current or previous frame and then the paint occurs.
@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 9, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
action: merge The PR is ready for merge by the caretaker cla: yes PR author has agreed to Google's Contributor License Agreement target: patch This PR is targeted for the next patch release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants