[
https://issues.apache.org/jira/browse/CALCITE-2703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16705864#comment-16705864
]
Stamatis Zampetakis commented on CALCITE-2703:
----------------------------------------------
The first reason to skip dynamic functions is the restriction imposed by the
Javadoc shown below:
{code:java}
/**
* @return true iff it is unsafe to cache query plans referencing this
* operator; false is assumed by default
*/
public boolean isDynamicFunction() {
return false;
}
{code}
but the real reason is that some dynamic functions (e.g., RAND etc) have the
@Determinstic annotation which ends up creating static fields in generated
classes and this do not work well with the cache. Maybe we should re-consider
which functions we mark as determinstic.
{quote}
What do you mean by "server" here?
{quote}
I meant through the connection interface. Typically, connection indicates
connection to a server so that's how server came into the discussion. I know
that you don't have to start a server, sorry for the confusion.
> Reduce code generation and class loading overhead when executing queries in
> the EnumerableConvention
> ----------------------------------------------------------------------------------------------------
>
> Key: CALCITE-2703
> URL: https://issues.apache.org/jira/browse/CALCITE-2703
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Affects Versions: 1.17.0
> Reporter: Stamatis Zampetakis
> Assignee: Julian Hyde
> Priority: Major
> Labels: performance
> Fix For: 1.18.0
>
>
> The queries using Calcite's EnumerableConvention always end-up generating new
> java classes at runtime (using Janino) that are then instantiated using
> reflection. This combination of class generation and class loading introduces
> a big overhead in query response time.
> A quick profiling on our Company's internal test suite consisting in 4000
> tests with roughly 430000 SQL queries passing through Calcite we observed
> that a big amount of time is spend on code generation and class loading
> making the EnumerableInterpretable#toBindable method a performance
> bottleneck.
> Among the 430000 SQL queries there are many duplicates which are going to
> lead to the generation of exactly the same code Java. Introducing, a small
> cache at the level of EnumerableInterpretable class could avoid generating
> and loading the same code over and over again.
> A simple implementation based on Guava improved the overall execution time of
> the afforementioned test suite by more than 50%.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
