Bench builder API

[JaroslavTulach]

Pull Request Description

Designing new Bench API to collect benchmarks first and only execute them then. This is a minimal change to allow implementation of #7323 - e.g. ability to invoke a single benchmark via JMH harness.

Important Notes

This is just the basic API skeleton. It can be enhanced, if the basic properties (allowing integration with JMH) are kept. It is not intent of this PR to make the API 100% perfect and usable. Neither it is goal of this PR to update existing benchmarks to use it (74ac8d7 changes only one of them to demonstrate it all works somehow). It is however expected that once this PR is integrated, the newly written benchmarks (like the ones from #7270) are going to use (or even enhance) the new API.

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

• All code follows the style guides.
• All code has been tested:
  • Vector/Operations.enso continue to run

[radeusgd]

Looks great!

While we are at it, I think it could be worth to revisit the format of the output that Bench.measure does - maybe we should allow to register the results in the Bench class and its children and allow exporting to CSV? @Akirathan wouldn't that make then loading benchmark results much easier?

[JaroslavTulach]

register the results in the Bench class and its children and allow exporting to CSV?

Please generate this XML format, if you want to get on par with existing JMH support.

[enso-bot]

Jaroslav Tulach reports a new STANDUP for yesterday (2023-07-18):

Progress: - benchmarking discussions: #7270 (comment)

• proposing Bench builder API: Bench builder API #7324
• reporting issues: Execute (and analyze) single Bench.measure  #7323
• meetings
• review: Add benchmarks comparing performance of Table operations 'vectorized' in Java vs performed in Enso #7270 (review) It should be finished by 2023-07-19.

Next Day: Bugfixes, cleanup & performance

[Akirathan]

I don't think it is worth investing time in adding any more capabilities to the `Bench` Enso class, apart from designing the specs builder API. I was hoping that after the integration of #7101, the preferred way to invoke benchmarks, and collect data from benchmarks, will be via our new custom JMH runner. Trying to mimic the behavior of JMH in our Enso `Bench.measure` makes little sense now.

[enso-bot]

Jaroslav Tulach reports a new STANDUP for yesterday (2023-07-19):

Progress: - bench builder API merged: #7324

• helping with GraalVM update: Update GraalVM to 17.0.7 (23.0.0 JDK17) #7176 (comment)
• evaluating Engine fatal crash when adding a simple node #7335
• propagating PanicSentinel: PanicSentinel value isn't propagated via Vector & co. #7245 (comment)
• problem running tests: Update junit-interface #7338 (comment)
• trying to build Enso on windows: https://discord.com/channels/401396655599124480/1131116974261403648/1131153204890063038
• review "watcher rewrite": Allow external edits of project files #7322 (review)
• talking with Adam Bárta from http://lcnc.cz conference about Enso
• meetings It should be finished by 2023-07-19.

Next Day: Bugfixes, cleanup & performance