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

Separate delay for inactivity timeout #5

Open
huyz opened this issue Jul 22, 2011 · 7 comments
Open

Separate delay for inactivity timeout #5

huyz opened this issue Jul 22, 2011 · 7 comments

Comments

@huyz
Copy link

huyz commented Jul 22, 2011

In my case, the responsiveness of the final call in a throttle is very important.
So I think I need a separate inactivity timeout.

For example, if some event happens during scrolls (say maybe every 5ms), it's nice to space out the actual callback calls to maybe 250ms, but once the scrolling is done, I would like the final callback call to come very quickly, maybe after 50ms of no calls to the throttled function. This is important to make things look right for the user.
I don't want to lower the current delay to 50ms because it slows down my page a lot.
Notice in my example that: 5 ms average interval < 50 ms < 250 ms

If you have no time for this, I could code it with a few tips from you to speed things up.

@cowboy
Copy link
Owner

cowboy commented Jul 22, 2011

How would the code know the difference between when to use the 250ms "throttle" behavior and the 50ms "trailing" behavior?

@huyz
Copy link
Author

huyz commented Jul 22, 2011

EDITED: first version of this post had bad examples.
EDITED: second version had a bug in the code. no need to have multiples

Based on inactivity. Right now, the delay does double-duty.
The current delay actually bears two distinct meanings:

  1. the maximum interval in which more than one function call is considered excessive and needs to be throttled. This is also the delay between the last throttled function call and the final callback call.
  2. how often the callback is called during bursts of function calls
    Currently the code has those as equal numbers, but they don't have to be. Of course, it only makes sense to use the plugin if (1) <= (2) but it's theoretically possible to have (1) > (2)

Let's give those names with examples:

  1. finalDelay = 50 (another name could be burstInterval)
  2. interDelay = 250, which is a 5x multiple

So in the code, it would be just a few minor changes. You'd have the setTimeout to finalDelay.
But instead of checking for elapsed > delay, you'd check for elapsed > interDelay.

Do you see a bug in that?

Ideally, I would then have callback calls coming in at:
0, 250, 35 if the throttled function calls were at 0, 25, 50, 75, 100, 125, 150, 175, 200, 250
0, 250, 300 if the throttled function calls were at 0, 25, 50, 75, 100, 125, 150, 175, 200, 250

Let's say another throttled function call comes in right after. You'd have:
0, 250, 300, 351 if the throttled function calls were at 0, 25, 50, 75, 100, 125, 150, 175, 200, 250 and then 301.
You could even have this in an extreme scenario:
0, 50, 101, 152 if the throttled function calls were at 0, 51, 102
Even though we said the interDelay was 250ms, an extreme scenario could space them about 50ms anyway.

But that's fine by me. What's most important is twofold: (a) not to take up processing juice during bursts of activity and (b) responsiveness after the burst. What's less important is the resulting spacing of the callback calls. It could be about 250ms with a final call of 50ms. Or it could turn out, as in the extreme scenario above, to be on average 50ms -- that's fine because I know that there were processing cycles available in the gaps between my bursts, as defined by my 50ms finalDelay (a.k.a. burstInterval).

In my particular case, the throttled function calls are event handlers on DOM modification events. In other words, not only is there a burst of function calls but these function calls are accompanied by a lot of other activity. So it's not just my callback function that slows down the machine, but other activity associated with the bursts, and that activity has priority. And when that activity is quiet, then my callback function has the next priority and needs to be responsive.

@huyz
Copy link
Author

huyz commented Jul 24, 2011

I put my mods into production: http://huyz.us/google-plus-me/
Seems to work fine with the 6000+ users on Google+ using my extension.

@huyz
Copy link
Author

huyz commented Aug 8, 2011

32000 users and no bug yet....

@cowboy
Copy link
Owner

cowboy commented Aug 8, 2011

Thanks for the updates. This is definitely on my list of things to work on, I just haven't had time yet!

@huyz
Copy link
Author

huyz commented Aug 8, 2011

Heheh yeah I feel you. I have so many feature requests from users and I need to work on a G+ Extension SDK...

@DiegoYungh
Copy link

Is this already implemented?
Here or in Lodash at least?
4 years passed 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants