JMH performance help regarding InternalDataSerializer.basicReadObject

[Udo Kohlmeyer <ud...@apache.org>]

Hi there Geode Devs,

I have a problem that needs some input...

In bb87f20a2317bb40e2218ec11d467591 
<https://github.com/apache/geode/commit/58c5dc700f278c2bff64d7965b6ff12b7274ce16#diff-bb87f20a2317bb40e2218ec11d467591> 
I refactored InternalDataSerializer 
<https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/InternalDataSerializer.java>, 
from using `if` statements to a `switch` statement, to an improved more 
readable/maintainable of InternalDataSerializer.basicReadObject 
<https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/InternalDataSerializer.java#L2754-L2919>.

This change was never benchmarked, given its obvious improvement over 
the previous implementation.

In a recent refactor, the reverse lookup DSCodeHelper 
<https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/util/DscodeHelper.java> 
and `switch` statement was replaced with a single O(1) lookup from 
`byte` to function.

In order to prove that this implementation is "better" or more 
efficient, it was thought to write a jmh benchmark, to quantitatively 
prove this.

Whilst looking at this, I realized that there around 70 different data 
types that this method can deserialize. In my, possibly flawed, 
thinking, I wanted to write a benchmark to ensure that I use all types. 
BUT as you can imagine, this would be an insurmountable task.

Are the any recommendations on how to best achieve this task of 
effectively benchmarking this method to prove or dispel the notion that 
a single lookup from byte->function is faster than byte->Enum and then 
switch(Enum)->function?

--Udo