anchor.diff:  JavaCompiler        avgt   60  2.726 ± 0.026  ns/op //   5% slower
   LamdbaMetafactory   avgt   60  3.453 ± 0.034  ns/op //  33% slower
   ----
  +
  +Your mileage may vary.
  
positive.code: this time using LamdbaMetafactory to access planning variables, _the score calculation speed was 9% faster overall_.
  However, the profiling (using sampling) still shows a lot of `executeGetter()` time, but less than with reflection.
  
  Further benchmarking is needed to measure the bootstrap, metaspace and megamorphic impacts.
  
  == Conclusion
  
  In this benchmark, reflection and (usable) MethodHandles are twice as slow as direct access in OpenJDK 8.
  Generated code is as fast as direct access, but it's a pain.
  LamdbaMetafactory is almost as fast as direct access.
  
  
negative.code: Note that in normal use cases, that performance gain will hardly be detectable,
  due to massive CPU needs of a realistically complex score calculation...
  
  One downside of code generation at runtime is that it infers a noticeable bootstrap cost (as discussed later),
  especially if the generated code isn't compiled in bulk.
  So I am still hoping that some day MethodHandles will get as fast as direct access,
  just to avoid that bootstrap cost and the dependency pain.
  