shared setTimeout()

[Yosh]

currently each send() call runs on its own setTimeout() call which causes a fair bit of lag - we should pool them similar to how process.nextTick() works - this'll save us a whole lotta delay on average, probably

[David Guttman]

Something like this? https://www.nczonline.net/blog/2009/08/11/timed-array-processing-in-javascript/

Basically, call as many as you can in 50ms, then take a break before doing the next bunch.

[Anand Thakker]

@yoshuawuyts As I found in a recent project using barracks, this problem can actually get quite a bit worse if there are lots of other scripts on the page (we were building components that were being embedded on pages w/ a lot of stuff already going on).

My solution was to--very carefully--fork barracks and remove the setTimeout entirely. That's probably not what you want for barracks itself, but I think that using next-tick instead of setTimeout might be a good solution, because it uses MutationObserver when supported to ensure callbacks are resolved as microtasks at the end of the current script/timer execution, rather than being queued behind other events or tasks.

One caveat: beware that by default, next-tick will use browserify's implementation of process.nextTick instead of its own, so a slight hack (or a change to node-process) would be required in order to actually get the MutationObserver implementation to be used.

[Yosh]

Oh, that's actually a really good suggestion - I keep hearing about this
microtask thing and it sounds heaps good; will have to read up on it. Glad
barracks worked for you on your last project by the way; ended up looking
heaps cool! :D

Would something like next-tick work for the use case you had on your
project?

On Mon, Nov 14, 2016 at 6:33 PM Anand Thakker [e-mail]
wrote:

@yoshuawuyts https://github.com/yoshuawuyts As I found in a recent
project using barracks, this problem can actually get quite a bit worse if
there are lots of other scripts on the page (we were building components
that were being embedded on pages w/ a lot of stuff already going on).

My solution was to--very carefully--fork barracks and remove the
setTimeout entirely. That's probably not what you want for barracks
itself, but I think that using next-tick
https://github.com/medikoo/next-tick instead of setTimeout might be a
good solution, because it uses MutationObserver when supported to ensure
callbacks are resolved as microtasks at the end of the current script/timer
execution, rather than being queued behind other events or tasks.

One caveat: beware that by default, next-tick will use browserify's
implementation of process.nextTick
medikoo/next-tick#9 instead of its own, so a
slight hack (or a change to node-process
https://github.com/defunctzombie/node-process) would be required in
order to actually get the MutationObserver implementation to be used.

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
#74 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACWlegrHw1nzz18oFz_9kuVckljKcs0Iks5q-I1dgaJpZM4KhSaM
.

[Anand Thakker]

@yoshuawuyts Yeah, I think next-tick essentially would have worked--in fact, I did use it in a couple of other parts of the project.

In our specific case, I opted not to simply change barracks's setTimeout() to nextTick(). Instead, I hacked send to make it dispatch synchronously by default, because that was the quickest way for me to make sure certain remote requests were fired off as soon as possible... BUT, the only reason I did it that way was because it was very last-minute and I didn't have time to do much refactoring--this was really just a last minute hack.

[Yosh]

Cool, thanks for sharing! Feeling confident having a nexttick solution will
be the right move :D

On Wed, Nov 16, 2016, 17:47 Anand Thakker [e-mail] wrote:

@yoshuawuyts https://github.com/yoshuawuyts Yeah, I think next-tick
essentially would have worked--in fact, I did use it in a couple of other
parts of the project.

In our specific case, I opted not to simply change barracks's
setTimeout() to nextTick(). Instead, I hacked send to make it dispatch
synchronously by default, because that was the quickest way for me to make
sure certain remote requests were fired off as soon as possible... BUT, the
only reason I did it that way was because it was very last-minute and I
didn't have time to do much refactoring--this was really just a last minute
hack.

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
#74 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACWlescBQvHnRxhVvKCtyjVN5gsSLCq2ks5q-zOCgaJpZM4KhSaM
.