[
https://issues.apache.org/jira/browse/DAFFODIL-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16329361#comment-16329361
]
Michael Beckerle commented on DAFFODIL-1877:
--------------------------------------------
The setContextsForChildren just connects the children to the parent. It's
required whether you set this node's host to null or a value. It's just about
the API way the graph of components was assembled. For expressions they aren't
"wired" with backpointers to their parents as they are constructed, but are
parents-pointing-to-children only, until this setContextsForChildren is called.
Error propagation depends on these backpointers (currently - something we need
to think about changing to increase sharing).
> 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)
