Add some microbenchmarks for Coders and DoFnReflector

[bjchambers]

Be sure to do all of the following to help us incorporate your contribution
quickly and easily:

• [*] Make sure the PR title is formatted like:
  [BEAM-<Jira issue #>] Description of pull request
• [*] Make sure tests pass via mvn clean verify. (Even better, enable
  Travis-CI on your fork and ensure the whole test matrix passes).
• [*] Replace <Jira issue #> in the title with the actual Jira issue
  number, if there is one.
• [*] If this contribution is large, please file an Apache
  Individual Contributor License Agreement.

---

[bjchambers]

R: @davorbonaci @kennknowles

Here is a strawman PR to introduce some microbenchmarks for pieces of the SDK potentially in the critical path. This focuses on the cost of calling processElement in a DoFn using the various mechanisms available.

[davorbonaci]

@dhalperi, this is important process-wise and how we manage changes in the benchmarks.

[bjchambers]

Added some microbenchmarks for Coders and cleaned up the build issues.

[kennknowles]

Do you get legitimate results from an invocation such as mvn exec:java -DmainClass=<whatever> or is there something wrong with that? Just to see if this might be a one liner.

[bjchambers]

I don't think so, based on reading on Stackoverflow. My goal here is to get the microbenchmarks added for datapoints in other PRs. Let's look into how we can get JMH benchmarks into some database separately, possibly via mvn, etc.

[kennknowles]

Do the benchmarks depend on package-private stuff? I'd prefer to avoid the split package, meaning that we would put this stuff somewhere under a new benchmarks namespace or some such rather than the namespaces from the core SDK.

[bjchambers]

They did depend on package-private stuff, but I made it public and moved them into their own microbenchmarks package. I could conceive of wanting to use package-private stuff in the same way tests do, but we can always do so by adding a thin wrapper to expose methods to benchmarks.

[kennknowles]

LGTM. And since there is no backwards-compatibility necessities I am very comfortable merging and if another committer has a better idea of how to organize things it is easy to adjust. Self merge any time, or feel free to solicit other opinions.

[dhalperi]

link this

[dhalperi]

Looks like there's no tests run under normal situation. How do we prevent bitrot?

[kennknowles]

That's a great point about bitrot. It should suffice to run the benchmarks on a tiny amount of input to ensure that they build & don't crash.

[bjchambers]

I've added links. I plan to submit as is (since these benchmarks add value). The most likely bitrot is prevented by getting them in and compiling regularly. We should look at either (1) adding explicit unit tests for them -- a bit odd since benchmarks are already test-like or (2) including the benchmark runs in some nightly runs and putting them on a dashboard somewhere. I think (2) is the most preferable solution to preventing bitrot.