Async Runner with Message Channel

[flashdesignory]

As discussed in our sync, here is a combination of the AsyncRunner and Message Channel pr.

Relevant code snippet (udpated):

class AsyncRAFTestInvoker extends BaseRAFTestInvoker {
    static mc = new MessageChannel();
    _scheduleCallbacks(resolve) {
        let gotTimer = false;
        let gotMessage = false;
        let gotPromise = false;

        const tryTriggerAsyncCallback = () => {
            if (!gotTimer || !gotMessage || !gotPromise)
                return;

            this._asyncCallback();
            setTimeout(async () => {
                await this._reportCallback();
                resolve();
            }, 0);
        };

        requestAnimationFrame(async () => {
            await this._syncCallback();
            gotPromise = true;
            tryTriggerAsyncCallback();
        });

        requestAnimationFrame(() => {
            setTimeout(() => {
                gotTimer = true;
                tryTriggerAsyncCallback();
            });

            AsyncRAFTestInvoker.mc.port1.addEventListener(
                "message",
                function () {
                    gotMessage = true;
                    tryTriggerAsyncCallback();
                },
                { once: true }
            );
            AsyncRAFTestInvoker.mc.port1.start();
            AsyncRAFTestInvoker.mc.port2.postMessage("speedometer");
        });
    }
}

For testing purposes I kept an explicit type of "async" in the test file, but I opted all default suites into using it.

Initial testing shows that it should also fix the react specific issue.

Other issue solved by this pr: #83

[flashdesignory]

Can we split the change to remove measurementMethod into a separate PR? We should also update params.mjs and developer-mode.mjs.

ok, reverted for now. I agree a cleanup pr to remove this would be better.

[bgrins]

@smaug---- I pushed this to https://feature-async-runner-message-channel--speedometer-preview.netlify.app/ for anyone who wants to test.

[rniwa]

Instead of changing the test runner based on the suite type for some suites, can we initially add a toggle to developer menu so that we can try out async runner?

[camillobruni]

To my understanding the agreement in the meeting was to unconditionally enable the new runner for the preact workloads and add the global developer-mode menu in a separate PR.

[flashdesignory]

correct - below is the list on enabled suites (for now):

• TodoMVC-React-Complex-DOM,
• TodoMVC-React-Redux,
• TodoMVC-Preact-Complex-DOM, (technically not react based, but it's similar)
• NewsSite-Next,
• React-Stockcharts-SVG

[rniwa]

If we're doing that, we need before/after numbers across browsers.

[flashdesignory]

I'll run crossbench for the ones on the list and post results here.

[flashdesignory]

Here are metrics for the next.js workload:

[rniwa]

So Safari's total time goes up while the total time for Chrome & Firefox both go down? With that kind of magnitude of a difference, we need a much more thorough investigation before we can approve of the change. I suggest we land this method initially as an optional developer-menu only feature instead.

[flashdesignory]

I'll add an option for the developer menu 👍

[smaug----]

Looks reasonable

[flashdesignory]

@rniwa - I believe we addressed all the comments. Anything else missing that I can help with?

[rniwa]

It is a bit suspicious to alway trigger the workload in rAF in this asynchronous measurement method.
A real web apps don't necessarily always wait for rAF to trigger any work so for the maximal realism, it might be better if we just triggered sync callback at a pseudo-random time relative to rAF.

[flashdesignory]

Do you mean just rmaking _scheduleCallbacks async and removing this raf here?

[rniwa]

So I think we need to wait for any promises scheduled in setTimeout get resolved so I think we need an await here.

[flashdesignory]

I'm not sure what we are awaiting here, since that just runs the check-in function tryTriggerAsyncCallback in the setTimeout. Would you mind giving me an example of what you had in mind?

[rniwa]

What I mean is to do this:

await Promise.resolve();

This will ensure that any promises scheduled during setTimeout will get resolved before we set gotTimer to true.

[rniwa]

Ditto here. I think we need to wait for any promises that got scheduled as a result of postMessage to get processed before we finish the measurement.

[flashdesignory]

Same here: code example would help, which I assume would be similar to above.