[
https://issues.apache.org/jira/browse/DAFFODIL-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16329049#comment-16329049
]
Steve Lawrence commented on DAFFODIL-1877:
------------------------------------------
The culprit appears to be this change:
{code:java}
def init() {
- this.setOOLAGContext(null) // we are the root.
+ this.setOOLAGContext(host) // we are the root of expression, but we propagate
diagnostics further.
this.setContextsForChildren()
}
{code}
It's not immediately clear to me why this has such a drastic performance
impact. Should 'host' also be passed to setContextsForChildren? Otherwise it
will set 'this' as the context for children. Is setContextsForChildren even
needed if host should just always be used and appears to be passed around where
needed? Also, now that it seems errors are carried on the host, should
Expression's even be an OOLAGHost?
> Slow schema compilation due to unambiguous checks
> -------------------------------------------------
>
> Key: DAFFODIL-1877
> URL: https://issues.apache.org/jira/browse/DAFFODIL-1877
> Project: Daffodil
> Issue Type: Bug
> Components: Front End, Performance
> Reporter: Steve Lawrence
> Priority: Major
> Fix For: 2.1.0
>
>
> Commit 02c8324294ed4395c1231c6ea3ec6ae77139ba46 caused ATO schema compilation
> time to jump from about 10 seconds to over 2 minutes. Large increases were
> also seen in VMF schema compilation.
> Some debugging showed that the cause is likely in the
> DFDLPathExpressionCompiler. Wrapping the following code the compiles an
> individual expression in a Timer shows an average of 9000% increase in time
> to compile.
> ```scala
> val compiler = new DFDLPathExpressionParser[T](qn,
> nodeInfoKind, namespaces, compileInfoWherePropertyWasLocated,
> isEvaluatedAbove)
> val compiledDPath = compiler.compile(expr)
> compiledDPath
> ```
> So this most likely has something to do with schema compilation. Nothing
> jumps out at me in the specified commit as being especially egregious to
> cause such a performance degredation. All the really changed was passing an
> extra parameter for error accumulation and changing how
> isReferencedByExpressions is set. I wouldn't expect that to cause such
> performance changes. Perhaps it is findNamedMatches now allocating a Seq?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
