[
https://issues.apache.org/jira/browse/DAFFODIL-2627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17483857#comment-17483857
]
Steve Lawrence commented on DAFFODIL-2627:
------------------------------------------
I think that might require logic to detect when a schema file (or anything it
recursively imports/include) changes so that we know to invalidate the cache?
I'm not sure what would happen if you run an sbt console (or IDE), run test,
make changes to the schema, and then run test again. Does sbt somehow throwaway
existing objects/the cache since files changed? Or will subsequent tests use
the same object? I'm not sure.
That also causes problems with things that aggregate a bunch of projects (like
our dfdl-schemas regression suite), where we really do need to throw away
cached schemas or we'll run out of memory. But maybe that's not a big deal, and
the solution is to run all the aggregate schemas separately. That's basically
what I do right now anyways.
> Performance regression in TDML processor
> ----------------------------------------
>
> Key: DAFFODIL-2627
> URL: https://issues.apache.org/jira/browse/DAFFODIL-2627
> Project: Daffodil
> Issue Type: Bug
> Components: TDML Runner
> Affects Versions: 3.2.0
> Reporter: Josh Adams
> Assignee: Steve Lawrence
> Priority: Major
> Fix For: 3.3.0
>
>
> While working on a customer project we noticed a significant increase in the
> amount of time it took to run our test suit (over 600 tests) after upgrading
> from Daffodil 2.7.0 to 3.2.1. We were seeing roughly a 4x increase in time
> to complete the same set of tests.
> I've narrowed the performance regression to commit
> 0700ee8dc9531497f3e8b0fdf9266f8e3b105c27 which involved a removal of the
> schema compilation cache, which is likely causing the schema to need to be
> recompile much more frequently.
> We use a relatively large schema (over 10,000 lines), but it is the same
> schema used for all tests.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
