debounce and throttle seems to decrease performance for window.onscroll

[gregg-cbs]

Hi,

Using this package I have done some tests in Firefox and I have noticed using debounce or throttle for window.onscroll function is worse then just allowing the function to run on every pixel scroll.

I wouldnt have thought this because i thought the debounce or throttle would prevent any operations from happening but it seems the operations the debounce/throttle does to debounce operations from happening is more expensive then the operations just happening.

It seems in firefox on every metric says using debounce or throttle for onscroll is worse for performance.
I guess I am putting this here for other developers and for discussion - using throttle and debounce is not always better.

Does anyone have anything to weigh in on this?
I am not a performance measuring pro.

thanks

[niksy]

@gregg-cbs have you noticed same issues with other implementation such as those in Lodash?

[TheThirdRace]

@gregg-cbs

Window.onscroll

You should never use window.onscroll directly because it's an active listener. With or without this package, this is a performance bottleneck.

Instead, you should use window.addEventListener('scroll', myFunction, { passive: true }).

The { passive: true } will make your listener passive, which translates to much better performance.

Performance

As for the claim this package makes scrolling worst, it's hard to tell without knowing how you tested it.

Note: In case of scrolling, we're talking about throttle, you don't want to debounce

Like any wrapper, this package will add code to be executed. More code executes slower than less code, it's a given. The trick is to figure out where the break even point of the wrapper is.

If the throttle delay is too short or too long, this will show janky scrolling.

Let's say your function takes 5ms to executes. Over 1 second, the function can execute 200 times, which is well over the 60 FPS for a smoot scrolling. The downside is that this function is using up all your CPU cycles over that 1 second, it's making everything else lag.

If adding the wrapper makes the function execution take 15ms instead. It's obviously less performant per execution, but that's not the whole picture.

Throttling with a 16ms delay would still give you a smoot 60 FPS scrolling. But you would only free 1ms for your CPU cycle to do something else...

Throttling with a 25ms delay would give you a relatively smoot 40 FPS scrolling. But you would free plenty of ms for your CPU cycle to do something else...

Throttling with a 100ms delay would give you a slow and janky 10 FPS

I'm not 100% sure with this last one, but throttling with a 5ms delay would add 3x the amount of executions in the queue. Since you can only execute a 15ms function 66.6667 times per second, the extra 133.3333 executions would execute after the 1 second threshold and would appear as if the function is lagging.

It's not about this package being less performant than a native function on a per execution basis, it's about how you can leverage the throttling to get the same performance over time and free up plenty of CPU cycles for something else.

[gregg-cbs]

I like the note about passive true, i will try that sometime and read into it.

In what you were saying above, the scroll or performance was not laggy or bottle-necked, its just that the cpu was being used more.

The debounce function runs on every scroll tick to check if the function inside of the debounce is allowed to run. It is that running of the debounce on every scroll tick that hogged the cpu more than just running the function inside of it - your calculations would need to be -> debounce_execution_time vs inner_function_execution_time, which ever is shorter should be used because thats more performant.

In my case it could be that my inner function was so simple that it was easier to run then running a debounce function which has a timeout mechanism and what ever is inside of it.

Maybe i did it wrong, maybe I dont know what I am talking about, but that is what I saw.

[haydenrust]

@TheThirdRace How does passive set to true translate "to much better performance"? According to mdn, all that does is "indicates that the function specified by listener will never call preventDefault"

[TheThirdRace]

@haydenrust

As far as I'm aware, it enables some browser optimizations, mostly for mobile usage.

I re-read the MDN definition and it wasn't as clearly stated as I though. I had to click on a link to a further section to see the real optimization it brings: https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/addEventListener#improving_scrolling_performance_with_passive_listeners