geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Udo Kohlmeyer <...@apache.org>
Subject JMH performance help regarding InternalDataSerializer.basicReadObject
Date Mon, 10 Dec 2018 20:18:39 GMT
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


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message