Proposal: parameters and programmatic API

[Richard Warburton]

Hi,

Looks like a good step forward, only one comment.

+++ b. Parametric Java API
>
> This parameter notation opens up the way to execute the benchmark from
> the Java API. The proposed syntax is as follows:
>
>   Result execute(Class<T> benchmarkClass,
>                  String test,
>                  Settings settings);
>
> ...where Settings is the special class holding the parameters (and also
> environmental parameters, see below). Letting Settings have the proper
> builder will allow us to execute the example benchmark from the previous
> section as follows:
>
>  Result r = execute(B.class, "test",
>                       Settings.set("N", 1000)
>                               .set("stride", 10));
>  // process r, get the metrics, etc.
>
> Fixing only one of the parameters will still allow JMH to traverse the
> projection of the configuration space, e.g. traverse the strides with N
> fixed, etc. We will amend this API as we unfold other parts of parameter
> story.
>
> +++ c. Command line parameters
>
> We would need some good way to map these parameters to appropriate
> command-line acceptors. Our general line of thinking is that command
> line executors should ultimately use the Java API to invoke JMH. That
> means the mapping of command line parameters to API calls is localized
> in the specific cli module; which is currently TBD.
>

The ability to take settings from some kind of Map<String,?> or Properties
file would be highly appreciated.  I know that's really only a question of
iterating over the entryset and adding things in, but I imagine its a
common enough case to bake into the actual API.

regards,

  Richard Warburton

  http://insightfullogic.com
  @RichardWarburto <http://twitter.com/richardwarburto>