Add benchmark for high pin_subpackage count recipe

[mbargull]

Description

This is a performance regression benchmark for gh-5224.

Checklist - did you ...

• Add a file to the news directory (using the template) for the next release's release notes?
• Add / update necessary tests?
• [ ] Add / update outdated documentation?

[codspeed-hq]

CodSpeed Performance Report

Merging #5246 will not alter performance

_{⚠️ No base runs were found}

_{Falling back to comparing mbargull:pin_subpackage-benchmark (60cce81) with main (3b1f4f1)}

Summary

✅ 2 untouched benchmarks

🆕 1 new benchmarks

Benchmarks breakdown

	Benchmark	main	mbargull:pin_subpackage-benchmark	Change
🆕	test_pin_subpackage_benchmark	N/A	116.9 s	N/A

[kenodegard]

@mbargull this looks promising! is this ready for review?

[mbargull]

@mbargull this looks promising! is this ready for review?

In principle yes.
IDK if we want to merge this yet, though, since it takes about 15 minutes CI time even in the further cut down version.
We could postpone merging this until we flesh out PRs addressing gh-5224 and base those PRs on this one in the mean time if we don't want to run this without improvements all the time.

[mbargull]

To simplify things, it would probably suffice only add the single-entry keys since their number is far greater than the other entries (and zip_keys).
As is, these numbers just closely recreate those from conda-forge's cbc.yaml.
(Overall, the impact on the variant size mostly affects the .config.Config.copy impact on the overall run time, I'd assume.)

[kenodegard]

I say we leave this for now, we can always simplify it later once we've achieved some speedup.

[kenodegard]

As long as the entire benchmark job completes under 30 min I'm ok with proceeding

I think there's value in getting to see the speed delta for this benchmark in the other PRs (we can always disable this once we've made the improvements)

[kenodegard]

I say we leave this for now, we can always simplify it later once we've achieved some speedup.

[mbargull]

Thanks for the review/merge 🙇 !

[mbargull]

Oh, one thing I kind of forgot was that by stripping the recipe down this much, I got rid of all of the selectors 🤭 .
Meaning, for the split_lines optimizations, this would, of course, only evaluate the changes for passing over all lines, but without any eval_selector(...) calls at all...