There is a disconnect between the named parameters like @OperationsPerInvocation and @Params. Named parameters provide the defaults for benchmark parameters, and may be regarded as user-tunable parameters. @Params provide the benchmark-specific (data) changes, and participate in the final reports.
It would be nice to understand if we can marry both classes of parameters, so that:
a) Users got the ability to provide the sequence of named parameters to try (e.g. @Threads({1, 2, 4}) without resorting to API. Just like @Params do.
b) Users get the named parameters in the final report, like they already have with @Params.
It would be nice to understand if we can marry both classes of parameters, so that:
a) Users got the ability to provide the sequence of named parameters to try (e.g. @Threads({1, 2, 4}) without resorting to API. Just like @Params do.
b) Users get the named parameters in the final report, like they already have with @Params.