[
https://issues.apache.org/jira/browse/DAFFODIL-2831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18046445#comment-18046445
]
Steve Lawrence commented on DAFFODIL-2831:
------------------------------------------
One consideration is our delimiter scanner does already have the ability to
scan for multiple variable-length delimiters. For example, we already support
things like dfdl:initiator="ABC: X:".
So to support variable length initiated content initiators, we could create a
single delimiter scanner at compile time that scans for all initiated content
initiators. And at runtime the choice parser would run the scanner and use the
found initiator to dispatch to the matching branch.
This is probably not as efficient as an optimization we could do if initiators
were all the same length (e.g. read N chars, look it up in a map), but it's
probably more efficient than what we do now (i.e. create an infoset element,
scan for a single initiator, backtrack, and repeat until an initiator is
found). Plus, the scanner is a relatively isolated component that could (and
probably should) be optimized separately.
> InitiatedContent performance isn't equivalent to choicedispatchkey performance
> ------------------------------------------------------------------------------
>
> Key: DAFFODIL-2831
> URL: https://issues.apache.org/jira/browse/DAFFODIL-2831
> Project: Daffodil
> Issue Type: Improvement
> Components: Middle "End", Performance
> Affects Versions: 3.5.0
> Reporter: Olabusayo Kilo
> Priority: Major
>
> One should achieve similar performance by an optimization of
> initiatedContent="yes". Having to do a by-hand optimization/workaround of
> choiceDispatchKey, with the corresponding ugly outputValueCalc, is definitely
> to be avoided.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
