You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It presents a stream with 100.000 updates, and two buttons to try two posibilities: use debounceTime from rxjs or use a custom (not finished) implementation that works with just one setTimeout
Expected behavior:
RxJS test takes a constant time, just like the custom implementation
Actual behavior:
RxJS test takes a linear time based on number of updates
Additional information:
There's a bit of discussion around debounce in #2834 and I can see that the implementation is not as straightforward as in the custom one, as there's an scheduler.
However, it should be posible to not cancel the task and re-create it on every message received, but use something similar to the custom implementation so that when the last task evaluates, it checks whether it needs to set up a new task or it can emit the last value straight away.
I think it's important to decrease the overhead of ignored messages, as one of the main points of debounceTime is to prevent processing quick succession of events.
I'm happy to contribute on this if you need some help.
The text was updated successfully, but these errors were encountered:
RxJS version:
6 and 7
Code to reproduce:
https://codesandbox.io/s/practical-poincare-gm0h6?file=/src/index.ts
It presents a stream with 100.000 updates, and two buttons to try two posibilities: use
debounceTime
fromrxjs
or use a custom (not finished) implementation that works with just onesetTimeout
Expected behavior:
RxJS test takes a constant time, just like the custom implementation
Actual behavior:
RxJS test takes a linear time based on number of updates
Additional information:
There's a bit of discussion around debounce in #2834 and I can see that the implementation is not as straightforward as in the custom one, as there's an scheduler.
However, it should be posible to not cancel the task and re-create it on every message received, but use something similar to the custom implementation so that when the last task evaluates, it checks whether it needs to set up a new task or it can emit the last value straight away.
I think it's important to decrease the overhead of ignored messages, as one of the main points of
debounceTime
is to prevent processing quick succession of events.I'm happy to contribute on this if you need some help.
The text was updated successfully, but these errors were encountered: