Varying OperationsPerInvocation

[Aleksey Shipilev]

On 02/20/2014 01:23 PM, Chris Vest wrote:
> Say I have a an API that can do operations in batch, and I want to
> measure how the size of the batches trade off latency and throughput
> in terms of the individual item in each batch.
> 
> Right now, I have to write a @GMB method for each batch size, since
> the @OperationsPerInvocation value gets inlined into the generated
> benchmarks, and cannot be adjusted from the command line or through
> OptionsBuilder.

Will it help to "just" expose the OPI setting in runtime options? It can
be done without sacrificing the benchmark performance.

Then you can do a

class B {
  @Param
  int batches;

  @GMB
  void test() {
    ...
  }
}

...which you can then call with:

void runWith(int batches) {
  new OptionBuilder()
    .param("batches", batches)
    .operationsPerInvocation(batches)
  ...
}

> What I am doing currently, is having a `private static final int` in
> my benchmark class, that gets initialised from a system property. I
> then use --jvmArgs to set the system property from the command line
> for the forked JVMs, and then just live with the fact that the
> numbers are for multiples of operations.

...and since you are using the API, and you know the batch size, you can
simply divide the metric programmatically?


> I was thinking that an approach to do this better, could be that the
> harness could expose a `public static final long` somewhere, that
> would be initialised to the value of an --opi (or whatever it would
> be called) argument,

Unfortunately, this lies within the interface between @Param and other
settings. We will address it some time later, but not immediately, sorry.

-Aleksey.