[
https://issues.apache.org/jira/browse/CALCITE-4539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17303703#comment-17303703
]
James Starr commented on CALCITE-4539:
--------------------------------------
Using JdbcTest.testJoinFiveWay, I ran the query six times then I took the last
3 results as reported by intellij. I then repeated this 3 times.
After bench marking Janio, my prototype and using legacy java reflections, I
found:
| |Janio||*Prototype*||*java reflection*||
|Average|326.4444444|315.5555556|1525.888889|
|Standard Deviation|27.12983188|14.75729575|75.8476177|
The prototype was a static code with out caching or cycle detection. I latter
added cycle detection and caching, but the results were with in one standard
deviation. So I didn't not follow up further.
I was doing the dispatch with instance of instead of scanning an array of known
classes.
{code:java}
if(node instanceof ...){
return handler.call((...) node);
} else if(node instanceof ...) {
return handler.call((...) node);
}....
{code}
If janino compiler dispatch was changed to use instanceof, it would remove the
requirement know all relnode subtypes. This allow the HandlerProvider revise
to be simplified to:
{code:java}
<H extends MetadataHandler<M>, M extends Metadata> H revise(
Class<H>, @Nullable RelMetadataProvider relMetadataProvider);
{code}
Since internally the janino compiler only needs a list of methods derived from
the handler class, and a distinct descriptive name that could also be derived
from the handler class.
> Support pluggable metadata handlers and caching
> -----------------------------------------------
>
> Key: CALCITE-4539
> URL: https://issues.apache.org/jira/browse/CALCITE-4539
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Reporter: James Starr
> Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Calcite janino backed metadata does not support all the functionality that
> the java reflection backed metadata system, such as customizing the cache to
> use soft refs or have a max size. Furthermore, the janino backed metadata
> provider has many opinion that other are not universally shared, such as lazy
> loading, requiring all rels to registered to a global singleton, use of
> thread locals. There is no easy way to currently override these opinions.
> Calcites metadata system should consist of 3 APIs: metadata consumer,
> metadata implementors, metadata behavior. The metadata consumer need to able
> to fetch the appropriate metadata and invalidate the cache. Currently this
> is all done through RelMetadataQuery with some very leaky abstractions.
> Metadata implementors create functions that extract the metadata for
> particular node types. These functions are registered via
> ReflectiveRelMetadataProvider and ChainedRelMetadataProvider. Attempting to
> configure the internal behavior does not currently have an api. Currently
> porptions of it a scattered through out various class and are frequently not
> extensible.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
