Measuring performance details

Time-slicing (fiber-based render-scheduling) will likely be introduced in React in the near future.

I have been helping out with a React-alternative myself for a couple of weeks now, which will also feature non-blocking render-scheduling, and I believe we are likely to see more libraries like this in the future.

How do we benchmark the performance of these libraries?

Merely measuring time taken seems like it’s going to favor frameworks without this feature - which seems unfair, given that this is a feature designed to improve perceived performance, e.g. by unblocking the UI thread for long enough to keep CSS animations running smoothly while rendering many slow components.

Two ideas:

1. Measure actual CPU usage while running the tests - most conventional frameworks will be at 100% on the CPU core running the JS main thread, while frameworks that implement time-slicing should be giving some time back. (This can’t be measured from JS, so it may be difficult to implement in practice. Presenting this data in a meaningful way may also be challenging.)

2. Measure maximum blocking durations - most conventional frameworks, for example, will block for the entire duration of rendering a large table, while frameworks that implement time-slicing will block only for as long as the slowest component instance takes to render. (This should be measurable using plain JS, e.g. by scheduling measurements with performance.now from a setInterval callback or something similar.)

Thoughts?

[krausest]

I’m closing older issues that won’t get fixed.

[yisar]

@mindplay-dk @ryansolid @localvoid Here is a new proposal that mentions some new performance testing. Such as total-blocking-time, which is useful for react or fre. We can’t just rely on testing the total rendering time to judge the performance. The total blocking time is a good way.

https://wicg.github.io/largest-contentful-paint