CI benchmarking suite

[MilesCranmer]

(Merge after #618)

This defines a simple BenchmarkTools.jl suite based on BENCHMARKS.md for the actual benchmark code. Feel free to add other things we should be keeping track of or maybe some integration benchmarks.

This also uses AirspeedVelocity.jl for automatic CI output which parses the output of the benchmark results. Basically every pull request will get a comment like SymbolicML/DynamicExpressions.jl#94 (comment) with all of the performance info. It also measures the change in load time which is quite useful.

I find it nice for catching performance regressions in PRs.

[MilesCranmer]

I added @ericphanson's GC benchmarks here too via git cherry-pick

[MilesCranmer]

Here's the new results, comparing #529 with main:

	main	dirty	main/dirty
basic/@py/pydict/init	0.194 ± 0.006 ms	0.209 ± 0.0064 ms	0.925
basic/@py/pydict/pydel	0.199 ± 0.007 ms	0.217 ± 0.0072 ms	0.915
basic/julia/pydict/init	0.187 ± 0.014 ms	0.195 ± 0.0074 ms	0.959
basic/julia/pydict/pydel	0.191 ± 0.0064 ms	0.209 ± 0.0067 ms	0.917
gc/full	1.07 ± 0.031 s	1.19 ± 0.012 s	0.901
time_to_load	0.666 ± 0.049 s	0.666 ± 0.0045 s	1

Does this make sense? A bit slower GC, but now with thread safety?

[MilesCranmer]

Hey @cjdoris I updated to the proper workflow version of AirspeedVelocity.jl: https://discourse.julialang.org/t/easy-github-benchmarking-with-new-airspeedvelocity-jl/129327.

It uses a job summary. You can see the benchmark results here. Using this, one can quickly check this table on a PR to validate if a change hasn't caused a slowdown or anything. It also now reports memory and allocations which has been useful!

(We can also switch to the GitHub comment version if you prefer.)

Does this sound good to you?

[MilesCranmer]

I'm rebasing on #618 to see if that fixes the bus error in the benchmark. The benchmark is heavy on the GC so it makes sense it would hit this kinda stuff.

Edit: yep!