[
https://issues.apache.org/jira/browse/CALCITE-4551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17308905#comment-17308905
]
James Starr commented on CALCITE-4551:
--------------------------------------
[~zabetak], I am trying to add support for pluggable interface for metadata
handler generation and caching(CALCITE-4539). This will help me migrate my
company from the legacy java reflection base metadata api to janino generated
handlers. While doing this initial investigation, I generated static handlers
for meta data query that did not have caching, and did performance comparison
using JdbcTest.testJoinFiveWay comparing my hand rolled handlers, the generate
handlers via janino, and metadata using java reflections. I observed that
query actually ran faster without any metadata caching, however, it was within
a standard deviation so it was clear that JdbcTest.testJoinFiveWay was no
longer a good way of stress testing the meta data system since most of time was
no longer spent in planning. Concerning JMH, unless I am missing some already
previous integration calcite already has set up, it seems like needless
overkill to set up another harness to get the same numbers.
To clarify, I am testing 3 variables and not exhaustively. First, the value
used in the cached key, second, wether cached key value was reused or created a
new every time, and what is the underlying cached.
||Backing Cache||{color:#de350b}HashBasedTable{color}||{color:#00875a}Map of
Maps{color}||{color:#de350b}HashBasedTable{color}||{color:#de350b}HashBasedTable{color}||{color:#de350b}HashBasedTable{color}||{color:#00875a}Map
of Maps{color}||
||Key||{color:#de350b}Flatten(Object,
Integer){color}||{color:#de350b}Flatten(Object,
Integer){color}||{color:#de350b}FlattenList(Object,
Integer){color}||{color:#de350b}FlattenList(Object){color}||{color:#00875a}Object{color}||{color:#00875a}Object{color}||
|Fly
Wheel|{color:#de350b}NO{color}|{color:#de350b}NO{color}|{color:#00875a}Yes{color}|{color:#00875a}Yes{color}|{color:#00875a}Yes{color}|{color:#00875a}Yes{color}|
|Average|119.55|99.14141414|104.9|99.03|91.34|51.6969697|
|Standard
Deviation|11.04844703|4.733747924|11.39865312|9.235914747|8.150379554|1.656493379|
I am using java version 1.8.0_251.
I dropped the String key because that was only generated due to bug and is not
actually being considered. These tests results are very constituent across
runs with average and deviation not varying much. The standard deviation is
high because GC is the chaos agent but is still fairly predictable over a high
number of runs. When object creation is removed, then GC is no longer a chaos
agent and the standard deviation drops to very close sample error of the
harness.
To answer [~julianhyde] original question, no the JVM is not optimizing away
the object creation.
> Fly Weight for MD Cache Keys
> ----------------------------
>
> Key: CALCITE-4551
> URL: https://issues.apache.org/jira/browse/CALCITE-4551
> Project: Calcite
> Issue Type: Improvement
> Reporter: James Starr
> Priority: Major
> Labels: pull-request-available
>
> Create cache keys for metadata calls generates a fair bit of object turn in
> trivial cases, more expensive than the actual metadata call. Many metadata
> calls could reuse their cache keys since the are functionally identical.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
