Naming commands behaves unexpectedly when using parameters
Closed this issue · 1 comments
When naming commands in hyperfine, it's pretty clear that given N commands and M names:
- M must be less or equal than N
- and command 0 will get name 0, command 1 will get name 1, command M will get name M, command M + 1 will get the default name, and so on
However, when using parameters, these rules seem to change arbitrarily, and the only allowed way to use command names is to either specify it 0, 1, or as many times as benchmarks will be run.
I think this is problematic because:
- There are no clear rules respecting the order in which names must appear; the end user has no idea in which order hyperfine will instantiate commands (and they shouldn't have)
- And it means hyperfine must respect the order of instantiation, or it'd be breaking compatibility
- The number of names to be given (if expecting to name every command) grows quite quickly
- If using more than one command with parameters and a single name, all commands are given exactly the same name, making the feature useless (
hyperfine -n "a{foo}" -L foo 1,2 "echo {foo}" "sleep {foo}")
My proposal for a solution would be to change slightly the way we understand commands and names when using parameters.
A command becomes a command template, and a command name is a command name template.
The rules between these two are the same ones described at the beginning of this post, each command name template corresponds to one command template (and is instantiated with it multiple times).
This change would be breaking, so I understand if it's decided not to be implemented. However, I think it would be interesting to consider it for hyperfine 2.0 #788 . Also, I don't think there's a lot of people using this feature, as shown by #793.