run commands only once per set of parameters they use

[c-cube]

My use case is a bit different than in #637 but I think the solution could be the same.

Basically I want to run command "foo", "bar", and "baz {A} {B} {C}" with parameters A, B, C. Currently "foo" and "bar" are run once for each combination of A, B, and C, which is inefficient and clutters the output. Instead, "foo" and "bar" should run only once each.

It could be done either by, after expanding all combinations, deduplicating commands (but then showing parameters is harder); or detecting which subset of parameter/scans each command takes and computing only the relevant combinations.

[fzlzjerry]

The important compatibility case here is a parameter used only in a preparation command: it still represents a distinct benchmark even when the measured command text is unchanged. Command names and setup/prepare/conclude/cleanup commands also need to be considered when deciding whether a parameter is relevant.

This issue is available for other contributors; the investigation notes here are offered for reference.

[fzlzjerry]

I reproduced the example on master: 24 benchmark entries for 10 distinct command lines. A separate check confirmed that a parameter used only by --prepare must still produce distinct benchmarks, so deduplicating the final command strings would lose valid cases.

One approach is to expand each command over the parameters used in that command, its name, or its setup/prepare/conclude/cleanup commands. Explicitly repeated commands and parameter values stay separate. When multiple per-benchmark names, preparation/conclusion commands, or output destinations are supplied, I'd retain the full matrix so their positions don't change.

For exports, each JSON result would contain only its relevant parameters; CSV would use the union of parameter columns, leaving irrelevant cells empty. #902 touches the related reference-command CSV case, so that overlap would need to be coordinated.

Would automatic pruning with those positional safeguards fit the direction discussed in #637, or would you prefer an opt-in mode?

Anyone is welcome to take this implementation forward.