Any boolean properties can be specified by true/false, yes/no, or on/off, and these values are case-insensitive.
| Property name | Effect | Default value |
|---|---|---|
| jbench.runs | Number of times to run each task | 5 |
| jbench.failfast | Whether or not JBench should abort completely if any of the tasks fail the configuration phase | false |
| jbench.log | Filename to save log to. If unspecified, System.out is used instead. | (Unspecified) |
| jbench.log.append | Whether or not to append to the log file (if specified - see above) rather than overwriting it | true (ie append) |
| jbench.stats.excludeworst | The number of worst results to exclude when calculating statistics | 1 |
| jbench.stats.excludebest | The number of best results to exclude when calculating statistics | 1 |
| jbench.timer | The timer implementation to use; either an alias
(cpu and clock being supported at the
moment) or the name of a class (with a public no-arg constructor)
which implements uk.org.skeet.jbench.JBenchTimer. See
Using the CPU timer for details of
how to use the cpu value.
| clock |
| jbench.timer.* | Properties to pass to the timer to configure it. Note that the
jbench.timer. part is stripped off each property before
being passed to BenchTimer.configure
| n/a |
| jbench.sysinfo | A comma-separated list of system properties to display.
Currently available properties are:
|
vm, os, timer |
| jbench.packages | A comma-separated list of packages to use when finding packages.
In fact, this is just a list of prefixes for classnames, so using a package entry
of com.mycompany and a classname of
app1.Benchmark will find
com.mycompany.app1.Benchmark. (The "." is automatically added
at the end of each specified prefix.)
An empty string is included at the end whether or not this properties is set.
|
(None - just the empty string) |
task.1.class, task.2.class etc until
task.n.class isn't found for some n.
(It will stop at the first number where a task isn't
specified - if you only specify 1, 2 and 4, for example, JBench will
only load the first two tasks.)
Loading the task consists of four steps:
task.(number).xxx=yyy to set property xxx
to value yyy. Global parameters may also be set using
properties of the form global.xxx=yyy. Global
parameters are set for all tasks. Note that task-specific
configuration parameters are set after global ones, so you
may effectively override global parameters. JBench will try to find
appropriately named methods with a single argument, and then try to
convert the string value into each type in turn, until a call succeeds
The name used is set plus the
name of the parameter with the first letter capitalised. For
example, in ListSort, the parameter
type makes JBench call setType.
If there are multiple overloaded methods with the same name, JBench
attempts to use them in order of specificity as far as possible, but
if two parameter types are unrelated (eg String and Class), the
order is undefined. In trying to convert the string value to a type,
JBench uses the ReflectionUtil class in the SkeetUtil library, which
converts primitive/wrapper types using appropriate
decode() methods for numbers, as well as trying the
system default NumberFormat. If the target type is not a primitive
or wrapper, SkeetUtil first looks for constructors which take a
single argument of the type of the source value (String in this
case), or a supertype. It then looks for any static methods in the
target class taking a single appropriate argument and returning a
type which is compatible with the target type. These methods are
sorted primarily by specificity (with the caveat about some ordering
being undefined, as above) and then by name, alphabetically. When
considering specificity, classes are always deemed more specific
than interfaces, which in turn are deemed more specific than
primitive types.
Note that the configuration method above started at v0.5 -
previously, only a predefined set of types were supported. Now, it's
easier to create tasks that (say) take a classname as a
configuration parameter, and that classname is automatically
converted into a Class object if a setXXX (Class foo)
method is declared. This can be seen in the rewritten ListSort task, with the
setType method. Many other types are accessible in the
same way, such as SimpleDateFormat, DecimalFormat and even Date
(although that uses a deprecated method). There are cases in which
the new configuration mechanism makes JBench less predictable -
namely when there you have overridden setXXX methods
with more than one type which can be converted to from a String.
This should always be avoided anyway, as even before v0.5 it would
have been confusing to the casual reader.
checkConfiguration is called on the task so
it can report any configuration errors by throwing a
ConfigurationException
If any of the steps fail, the task is not run. If
jbench.failfast is set to true, this will cause the
whole benchmark to stop. Note that two configured tasks may use the
same class - JBench treats them as entirely separate instances.
(The example configuration file shows one possible use for this. You
could also give each task a different size of test in order to
measure how the performance depends on size.)