Put benchmark boilerplate into subpackage

[gdalle]

Some code defining problem instances is used by tests and benchmarks, as well as external notebooks. Putting it in a package dispenses us from using include every time, and brings cleaner dependency management, at the cost of a Pkg.develop.

1. Create a subpackage in benchmarks/SparseConnectivityTracerBenchmarks to put:

• the Brusselator code
• the NLPModels code
• possibly the optimal power flow code or other stuff in the future

2. Use PkgJogger.jl to define the benchmark and run each @benchmarkable just once in the test suite

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.24%. Comparing base (34e6bec) to head (fb057af).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #136      +/-   ##
==========================================
+ Coverage   87.23%   90.24%   +3.00%     
==========================================
  Files          31       36       +5     
  Lines        1363     1455      +92     
==========================================
+ Hits         1189     1313     +124     
+ Misses        174      142      -32     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[adrhill]

Isn't that what the benchmark folder is for? Why don't we move everything in there and add a module and Project.toml?

[gdalle]

No, the benchmark folder is for benchmarking only, and has deps like BenchmarkTools. This code is used in tests, benchmarks and other places too. And it needs to be in a package to be importable in e.g. a Pluto notebook (to which I can give the exact GitHub URL of libs/SparseConnectivityTracerBenchmarks)

[gdalle]

The name may be ill-chosen, perhaps SparseConnectivityTracerProblems would be better?

[adrhill]

No, the benchmark folder is for benchmarking only

Not trying to be snarky here, but isn't libs/SparseConnectivityTracerBenchmarks also about benchmarking?

and has deps like BenchmarkTools

Is that a big issue? I think removing some complexity at the cost of one dependency is acceptable.

to which I can give the exact GitHub URL of libs/SparseConnectivityTracerBenchmarks)

Wouldn't benchmark be a URL that's just as viable?

[adrhill]

At the very least, we could move this into benchmarks/libs/SparseConnectivityTracerBenchmarks if this somehow is necessary for Pluto.

[gdalle]

Not trying to be snarky here, but isn't libs/SparseConnectivityTracerBenchmarks also about benchmarking?

See my latest comment, here I meant "benchmarks" in the sense of "benchmark instance definitions", not "full specification of a benchmark suite with sizes and evals and so on". Hence the possibility of an alternative name like SparseConnectivityTracerProblems or SparseConnectivityTracerInstances.

[gdalle]

Is that a big issue? I think removing some complexity at the cost of one dependency is acceptable.

This is pretty much a constant-complexity PR. It's just replacing the include with a using

Wouldn't benchmark be a URL that's just as viable?

It's not just about giving a URL, it's about giving the URL of a package (as opposed to including a file)

[adrhill]

Why did this have to be added?

[gdalle]

because it's used in the benchmarks

[gdalle]

@adrhill the benchmarks work on this PR branch and fail on main but that's expected, this is good to merge