Understanding performanceTimer metrics

Hi team.

I’m playing around with the performanceTimer config option for the first time. It seems pretty great. I can’t find much about how to interpret the output so wanted to get some clarification.

This is a sample output of running a single rule on a page:

gather ( 0 ): 8641.300000071526ms
axe.js:4923 Measure audit_start_to_end took 18.699999928474426ms
axe.js:4923 Measure rule_area-alt took 16.299999952316284ms
axe.js:4923 Measure rule_area-alt#gather took 15.800000071525574ms
axe.js:4923 Measure rule_area-alt#matches took 0ms
axe.js:4923 Measure runchecks_area-alt took 0.10000002384185791ms
axe.js:4923 Measure axe took 311.8000000715256ms

It looks like this last output is a measure of the total time it takes for the axe scan to complete from start to finish. What is audit_start_to_end?

I’m also trying to make sense of this gather output which doesn’t seem factored in the axe metrics. Could someone help me understand?

[straker]

Going to close this issue as I believe the questions were answered here or offline.

[straker]

Thanks for the issue. So the performanceTimer option is mostly used as an internal tool to gauge how each individual rule performs on a page. The time to run all the rules is measured with audit_start_to_end, and then generating the report and all the unique selectors is measured with axe.

After that, each rule has a few different outputs to let us know how each part of a rule is performing. So #gather is the step to find all the nodes in the current page that apply to the rule, #hidden is how long it took to make sure each node was visible, #matches is how long the rule’s matcher function took on all the gathered nodes, and runchecks is how long all the checks took for all the gathered nodes. Some of those are nested inside other measurements (like #hidden is a part of #gather), so the overall total time for rule is also measured for convenience.

You can see how we’ve used it to improve performance of axe-core with a currently opened pr.