anchor.diff:  ====
   It's recommended that the `benchmarkDirectory` is a directory ignored for source control and not cleaned by your build system.
   This way the generated files are not bloating your source control and they aren't lost when doing a build.
  -Usually that directory is called ``local``.
  +For example in git, it should be added to ``.gitignore``. Usually that directory is called ``local``.
   ====
   
   If an `Exception` or `Error` occurs in a single benchmark, the entire Benchmarker will not fail-fast (unlike everything else in Planner).
  
positive.code: 
  
  [[readingAnInputSolutionFromADatabase]]
  ==== Reading An Input Solution From A Database (Or Other Repository)
  
  The benchmark configuration currently expects an `<inputSolutionFile>` element, so a separate file, for each dataset.
  There are two ways to deal with this if your dataset is in a relational database or another type of repository:
  
  * Extract the datasets from the database and serialize them to a local file (for example as XML with `XStreamSolutionFileIO` if XML isn't too verbose).
  Then use those files an `<inputSolutionFile>` elements.
  * For each dataset, create a txt file that holds the unique id of the dataset.
  Write <<customSolutionFileIO,a custom `SolutionFileIO`>> that reads that identifier, connects to the database and extract the problem identified by that id. Configure those txt files as `<inputSolutionFile>` elements.
  
  
  [NOTE]
  ====
  Local files are always better: they allow for faster, more reliable, offline benchmarking.
  Otherwise, an unstable network connection can ruin a long running benchmark.
  ====
  
  
  [[warmingUpTheHotSpotCompiler]]
  
negative.code: == Benchmark Configuration
  
  
  [[addADependencyOnBenchmarkJar]]
  === Add a Dependency on `optaplanner-benchmark`
  
  The benchmarker is in a separate artifact called ``optaplanner-benchmark``.
  
  If you use Maven, add a dependency in your `pom.xml` file:
  
  [source,xml,options="nowrap"]
  ----
  