Move Perf Dashboard suite out of tentative directory.

[rniwa]

No description provided.

[camillobruni]

Generally looking good.

I reran this locally and noticed that the first run in a fresh tab (in all browsers), the first data point in Perf-Dashboard/Render/Async is quite a big outlier.

First-run in tab (Firefox):

Second-run in tab (Firefox):

In Chrome's DevTools, this is the main diff:

[camillobruni]

Firefox first step in first run in tab:

Firefox first step in second run in tab:

So I wonder whether we somehow have to put the canvas initialisation in the prepare step?

[camillobruni]

At least in Chrome it's a one-time-per-tab overhead for initialising font caches.
I can't imeditaley figure out whether that's the same case in other browsers.

[flashdesignory]

super nit: can we remove the console log here?

Speedometer/resources/perf.webkit.org/public/v3/components/interactive-time-series-chart.js

Line 243 in cfff701

console.log('_mouseDown', event.offsetX, event.offsetY, event.screenX, event.screenY, event.target, event.target.getBoundingClientRect());

it's printing out when running the test

[bgrins]

We're still looking into this and planning to continue throughout the week. One initial finding is that we are seeing significant time spent building iterators in generator functions. We don't currently optimize these very much because we haven't seen much evidence that they are performance critical in the wild.

It's not clear to me if this is an incorrect assumption and they are actually used widely / in performance critical ways (and thus we should be driving resources into optimizing this) or if the particular usage within this workload is somewhat unrepresentative of real world content (and thus the workload should be changed).

@camillobruni @rniwa do you have thoughts on this point (and/or data about usage of this feature)?

[rniwa]

We're still looking into this and planning to continue throughout the week. One initial finding is that we are seeing significant time spent building iterators in generator functions. We don't currently optimize these very much because we haven't seen much evidence that they are performance critical in the wild.

It's not clear to me if this is an incorrect assumption and they are actually used widely / in performance critical ways (and thus we should be driving resources into optimizing this) or if the particular usage within this workload is somewhat unrepresentative of real world content (and thus the workload should be changed).

@camillobruni @rniwa do you have thoughts on this point (and/or data about usage of this feature)?

Oh, interesting. I'm open to replacing that code but there is a bit of chicken & egg question here in that if we don't include anything that's already performance critical then we'd be sample-biasing to only test features that are already fast because authors would avoid using slow APIs in performance critical ways.

[rniwa]

At least in Chrome it's a one-time-per-tab overhead for initialising font caches. I can't imeditaley figure out whether that's the same case in other browsers.

Addressing this problem in #255.

[rniwa]

We're still looking into this and planning to continue throughout the week. One initial finding is that we are seeing significant time spent building iterators in generator functions. We don't currently optimize these very much because we haven't seen much evidence that they are performance critical in the wild.
It's not clear to me if this is an incorrect assumption and they are actually used widely / in performance critical ways (and thus we should be driving resources into optimizing this) or if the particular usage within this workload is somewhat unrepresentative of real world content (and thus the workload should be changed).
@camillobruni @rniwa do you have thoughts on this point (and/or data about usage of this feature)?

Oh, interesting. I'm open to replacing that code but there is a bit of chicken & egg question here in that if we don't include anything that's already performance critical then we'd be sample-biasing to only test features that are already fast because authors would avoid using slow APIs in performance critical ways.

I've put up a PR to avoid using generators in #256 but this doesn't seem to affect Firefox's score much so not sure if it's worth going that route.

[flashdesignory]

@rniwa - noticed the lint check fails. Just skimming through it, looks pretty straight forward.

[rniwa]

@rniwa - noticed the lint check fails. Just skimming through it, looks pretty straight forward.

I'm leaving those styling issues as is for now since they're happening inside the code being ported from perf.webkit.org. It's akin to having wrong formatting within a third party library/framework.

[flashdesignory]

@rniwa - noticed the lint check fails. Just skimming through it, looks pretty straight forward.

I'm leaving those styling issues as is for now since they're happening inside the code being ported from perf.webkit.org. It's akin to having wrong formatting within a third party library/framework.

if that's the case, do you want to add it to the ignore files, so the check passes?

[rniwa]

@rniwa - noticed the lint check fails. Just skimming through it, looks pretty straight forward.

I'm leaving those styling issues as is for now since they're happening inside the code being ported from perf.webkit.org. It's akin to having wrong formatting within a third party library/framework.

if that's the case, do you want to add it to the ignore files, so the check passes?

Good point. How do I do that?

[flashdesignory]

in the root are two files .eslintignore and .prettierignore.
You should be able to add the path there

[bgrins]

As discussed in the meeting today, r+ on this contingent on #256 (due to lack of data on generator usage)

[flashdesignory]

Approved - assuming the linters will ignore these files and conflicts will be resolved.