Measuring the time to complete task when run in a request animation frame.

[ivanceras]

When running the benchmark for sauron I noticed that if you use request_animation_frame on the executing the update/dispatch function it will register a longer time to complete than without using requestion_animation_frame.

Using request_animation_frame under the hood of patching the dom will significantly make the UI more responsive, and this is enabled by default in sauron, but there is no easy way to accurately measure the time it takes to execute the dom patching, other than the benchmark code have to hook into the underlying code for each framework.

There should be a better way to measure it. Thoughts?

[schell]

Are you talking about using request_animation_frame in mogwai or sauron? I'm assuming that you're optimizing saurons update/dispatch.

The way this benchmark measures the various updates is by submitting the required events and then polling the UI until all the updates are found. Sometimes this is done one event at a time and sometimes it is done by submitting a lot of updates in a "batch". I'm constantly trying to figure out the best way to do it (the "best" way being the most representative of an actual end user), but sometimes that is at odds with what works for a certain framework. This measurement is not the most accurate (there's no "true value") but it is rather precise in that the measurements for a given framework tend to be the same over successive runs. This is ok in my opinion because we really only care about how each framework compares to the others. I think a good new feature would be to include the standard error for each benchmark.

As far as speeding up sauron - using request_animation_frame is likely going to tie you to a 60fps update cycle. mogwai used to use set_timeout with a 0 millisecond timeout but we switched to a method using a callback queue backed by MessagePorts (https://github.com/schell/mogwai/pull/24). That was a two step process because I wanted to make sure that a callback that had been pushed onto the queue couldn't push even more callbacks onto the queue until at least the next frame - hopefully to avoid UI lockup (https://github.com/schell/mogwai/pull/25). All of that work was courtesy of @erikdesjardins (thank you!).

I'm not sure that answers your question but hopefully it gives us something to talk about!

[ivanceras]

Yes, I'm talking about request_animation_frame in the frameworks that uses it, I think most frameworks would use request_animation_frame when calling complex logic.

It seems polling the UI to find the updates may have been the cause of the reported execution time. Based on my benchmark with sauron, enabling request_animation_frame would report 3x as slow than without the request_animation_frame.

It looks like there is no better way to determine the execution time other than polling the UI.

Anyway, I wanted to port some of the js-framework-benchmark to rust, and this repo seems a good start to do it.

[schell]

I would gladly accept PRs or invite you as a collaborator and let you work on your own. This repo is not meant to be mogwai-specific even though it is written in it.