Computing JS duration only

[krausest]

This benchmark computes the duration as the duration from the click event until painting finished, i.e. this combines JS script duration and browser repainting. We had some request to report only the script duration.

A first attempt to use Performance.getMetrics etc. for that purpose, but some frameworks report way too low values (see #1233 (comment)).

So I switched back to computing the JS duration from the performance timeline. The basic idea is to add all relevant (top level) yellow bars and take that as the duration (for most cases there's just one bar), so it would be 2.09 ms for the example:

There are some special cases. Fre is a good example:

The first yellow bar is the click event (it's very small and not labeled), then we have three function calls. The number I'm getting from adding the durations of those bars is smaller than chrome's results in the pie chart. I think chrome adds GC duration which is also colored yellow (Labeled with "M..." in the screenshot).

I've added some logic to eliminate bars that are fully contained in other bars for situations like these:

react-hooks-use-transition is champion for the number of JS invocations with a total of 18:

[leeoniya]

i hate to sound like a broken record, but i think js-only is not the correct thing to do here because that misses frameworks where a bit of extra JS time may double the reflow/layout work due to sub-optimal dom ops.

it would be great to take the smallest reflow/layout/repaint and simply subtract it from the totals (which are already gathered), that would give the true overhead above baseline by leaving just js+gc+unneeded reflow/layout.

measuring just js+gc only makes sense if you know the rest is unaffected, but as i showed here, this is rarely the case and quite misleading: #1233 (comment)

[pascalvos]

I agree with @leeoniya mostly. @krausest rendering and painting time is also different for some frameworks solutions total time doesnt cover this completely
https://github.com/ChromeDevTools/devtools-frontend/blob/1061a013745d1f638b1f989204886232fd5a835a/front_end/panels/timeline/TimelineUIUtils.ts#L1180 has all the metrics in there i use this my self based on some of you ideas to test webcomponents and performance between releases i also opend a issue on here
https://bugs.chromium.org/p/chromium/issues/detail?id=1468139 asking on a more clear explanation i got almost the same results now as chrome dev tools.. except the part about forced layout and scripting as Paul also explains

there is a big difference when i render for example svelte wc, lit or vue wc having identical code there difference lies in rendering vs scripting and painting this mostly comes down if it uses vdom in vue or usage of constructed stylesheet in lit for example

this is the whole list is found here as a gist https://gist.github.com/vospascal/c989698871fb2c528ccc469c75eaec4f

Love to know what you all think about this