[jira] [Commented] (DAFFODIL-2238) couldHaveSuspensions - incorrect in many cases - needs unit tests

["Mike Beckerle (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DAFFODIL-2238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16979287#comment-16979287 ] 

Mike Beckerle commented on DAFFODIL-2238:
-----------------------------------------

Changing title to really reflect the task here, which is to make sure unparsers don't get generated with all these unnecessary unparsers in them that are supposed to be getting optimized out. 

For example, we generate ComputeContentLengthUnparser supposedly only for elements that are targets of a dfdl:contentLength(....) call. But that optimization doesn't work and so they're always being generated. This has no functional negative impact, it's just slow, and makes debugging - trying to figure out what the unparser is doing, really difficult.

> couldHaveSuspensions - incorrect in many cases - needs unit tests
> -----------------------------------------------------------------
>
>                 Key: DAFFODIL-2238
>                 URL: https://issues.apache.org/jira/browse/DAFFODIL-2238
>             Project: Daffodil
>          Issue Type: Bug
>          Components: Middle "End"
>    Affects Versions: 2.4.0
>            Reporter: Mike Beckerle
>            Priority: Major
>             Fix For: 2.5.0
>
>
> Many optimizations depend on the couldHaveSuspensions attribute, such as eliding out the expensive CaptureStart/End  of Content/Value length for unparsing. 
> This appears to be true far too often. The calculation is far too pessimistic. 
> E.g., in an example I have which is 100% text, with only constant dfdl:outputValueCalc expressions (because there are hidden flags that must be set to constant "1" or "0"), this attribute is true, yet there is no possibility of suspension in this example. 
> We need unit tests to insure this is being computed correctly so that the optimizations it enables will in fact take place. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)