These minor changes save a total of 50s out of the original 146s for each fidelity test run when run locally - thus a 32% savings. I know of a few more ways to save time (render the next test while evaluating the results of the current one, and then run tests in parallel), but this is the low hanging fruit.
These timings are from a Mac mini M2 Pro:
# Initial timing runs before these changes
% time npm run test
146.62s user 36.70s system 124% cpu 2:26.74 total
# Reuse browser, rather than creating a new one for each test. saves 42 seconds.
% time npm run test
60.20s user 4.59s system 61% cpu 1:44.97 total
# Create pages ahead of time, hides page creation time. saves 8 seconds.
% time npm run test
111.77s user 15.31s system 131% cpu 1:36.66 total
Also looking at this PR's CI time for the fidelity tests, it appears to have reduce the wall clock from 10m 36s to 8m 28s (2m 10s) for the test run. I am comparing it to the CI time on this other PR: https://github.com/google/model-viewer/pull/4542
These minor changes save a total of 50s out of the original 146s for each fidelity test run when run locally - thus a 32% savings. I know of a few more ways to save time (render the next test while evaluating the results of the current one, and then run tests in parallel), but this is the low hanging fruit.
These timings are from a Mac mini M2 Pro:
Also looking at this PR's CI time for the fidelity tests, it appears to have reduce the wall clock from 10m 36s to 8m 28s (2m 10s) for the test run. I am comparing it to the CI time on this other PR: https://github.com/google/model-viewer/pull/4542