Add Performance Regression Testing

[gatoWololo]

Lately there seems to have been a slowdown inadvertently introduced by one of our code changes. We should start measuring performance from commit to commit to ensure we do not suffer significant performance regressions, or at least understand the cost that our changes introduce.

I envision this working as follows: 1) Outline some useful set of micro and macro benchmarks that are indicative of our expected uses of this library.

The current benchmarks are a good place to start but take too long to execute. This may just be criterion attempting to run our benchmark too many times. I imagine a stripped down version of our current benchmarks, plus a few additional microbenchmarks. We could perhaps use our past results from the flame graphs to identify expensive functions or steps to execute as benchmarks.

2) Use criterion to compare performance from current commit to new commits.

Criterion is able to save the output of an benchmark execution and compare that to a new execution. Criterion can report statistically significant changes between executions. I believe we can combine criterion (which we already use) and hook it up with our CI to have major performance regressions reported on CI runs.

My main concern with this approach is that the GitHub Actions machines the CI runs on will have too much noise associated with them. Criterion does allow tweaking the noise parameter. So we may use that if the machine has too much noise.

[alankritdabral]

how can we use criterion to compare from current to new commits. can you explain how to perform this process @gatoWololo