[JBoss JIRA] (DROOLS-2787) "Data Type" tree-grid table interactions.
by Liz Clayton (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2787?page=com.atlassian.jira.plugi... ]
Liz Clayton updated DROOLS-2787:
--------------------------------
Attachment: Screen Shot 2018-07-27 at 11.48.34 AM.png
> "Data Type" tree-grid table interactions.
> -----------------------------------------
>
> Key: DROOLS-2787
> URL: https://issues.jboss.org/browse/DROOLS-2787
> Project: Drools
> Issue Type: Story
> Components: DMN Editor
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Labels: UX, UXTeam, drools-tools
> Attachments: DROOLS-2738.bmpr, Screen Shot 2018-07-24 at 3.51.03 PM.png, Screen Shot 2018-07-27 at 11.48.34 AM.png, add_basic.png, treegrid.png, type_definitions.pdf
>
>
> *Background*
> Persona: Business analyst or Rules practitioner
> Use Cases:
> As a user I want to:
> * *Edit* the list of Data Types, using the appropriate type considering the DMN model (eg: in the age line, we need to select "Numeric" in the combobox.)
> * *Add* a new data type, which might be a nested or otherwise complex object as defined by the (ItemDefinition.)
> * *Remove* Data Types from the list of available selections.
> * be prevented from making selections that are not valid or would cause an error.
> * know that when I edit a data type the changes will be updated in the DMN model.
> Functional considerations/ pre conditions:
> * Outside of simple view/select, Data Types list (and options) will be presented as a tree-grid within a modal dialog. Discussed in detail within Epic subtask for the same.
> * Design needs to be consistent with Stunner and PF components, such as: https://www.patternfly.org/pattern-library/widgets/#treegrid-table
> Verification conditions:
> * Scrum team and PO review.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (DROOLS-2787) "Data Type" tree-grid table interactions.
by Liz Clayton (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2787?page=com.atlassian.jira.plugi... ]
Liz Clayton commented on DROOLS-2787:
-------------------------------------
[~tirelli] [~manstis] Thanks for the pdf. But I believe my mockup doing the same thing (just a different way) - instead, I'm using a checkbox (to choose between Simple or Complex/Structure ) and you used Radio buttons. If you select the Simple option the non applicable elements are disabled.
!Screen Shot 2018-07-27 at 11.48.34 AM.png|thumbnail! So in this case you would define a type as "newPerson (Text)"
> "Data Type" tree-grid table interactions.
> -----------------------------------------
>
> Key: DROOLS-2787
> URL: https://issues.jboss.org/browse/DROOLS-2787
> Project: Drools
> Issue Type: Story
> Components: DMN Editor
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Labels: UX, UXTeam, drools-tools
> Attachments: DROOLS-2738.bmpr, Screen Shot 2018-07-24 at 3.51.03 PM.png, Screen Shot 2018-07-27 at 11.48.34 AM.png, add_basic.png, treegrid.png, type_definitions.pdf
>
>
> *Background*
> Persona: Business analyst or Rules practitioner
> Use Cases:
> As a user I want to:
> * *Edit* the list of Data Types, using the appropriate type considering the DMN model (eg: in the age line, we need to select "Numeric" in the combobox.)
> * *Add* a new data type, which might be a nested or otherwise complex object as defined by the (ItemDefinition.)
> * *Remove* Data Types from the list of available selections.
> * be prevented from making selections that are not valid or would cause an error.
> * know that when I edit a data type the changes will be updated in the DMN model.
> Functional considerations/ pre conditions:
> * Outside of simple view/select, Data Types list (and options) will be presented as a tree-grid within a modal dialog. Discussed in detail within Epic subtask for the same.
> * Design needs to be consistent with Stunner and PF components, such as: https://www.patternfly.org/pattern-library/widgets/#treegrid-table
> Verification conditions:
> * Scrum team and PO review.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (DROOLS-2799) DMN Optimize DT parameter binding for compilation
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2799?page=com.atlassian.jira.plugi... ]
Matteo Mortari updated DROOLS-2799:
-----------------------------------
Forum Reference: https://groups.google.com/forum/#!topic/drools-usage/dwqV_pH73Cw
> DMN Optimize DT parameter binding for compilation
> -------------------------------------------------
>
> Key: DROOLS-2799
> URL: https://issues.jboss.org/browse/DROOLS-2799
> Project: Drools
> Issue Type: Enhancement
> Components: dmn engine
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
> Attachments: AFTER.png, BEFORE.png
>
>
> Currently, DMN layer Evaluator method:
> {code:java}
> org.kie.dmn.core.ast.DMNDTExpressionEvaluator.evaluate(org.kie.dmn.api.core.event.DMNRuntimeEventManager, org.kie.dmn.api.core.DMNResult)
> {code}
> calls down to FEEL layer function:
> {code:java}
> org.kie.dmn.feel.runtime.functions.DTInvokerFunction.invoke(org.kie.dmn.feel.lang.EvaluationContext, java.lang.Object[ ])
> {code}
> In order to evaluate Decision Table using DecisionTableImpl.
> Currently, the whole Decision Table FEEL expression/UT are compiled to CompiledExpression and this enable for fast performance during execution and multiple evaluation, however, the parameter binding for the invocation from the DMN layer does not leverage FEEL expression compilation of the parameters ( information/knowledge requirements coming from the DRG graph ) hence the parameter binding is not really as fast as it could be across several evaluation.
> The current proposal leverage compilation for the parameter (names) which are actually FEEL expression, in order to move from this scenario:
> !BEFORE.png!
> to this:
> !AFTER.png!
> Conclusion the current proposal optimize the DMN parameter binding for the Decision Table invocation across several evaluations by at least an order of magnitude*
> {{*}} if compared to baseline, using a JUnit test part of the actual code base as benchmark
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (DROOLS-2799) DMN Optimize DT parameter binding for compilation
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2799?page=com.atlassian.jira.plugi... ]
Matteo Mortari updated DROOLS-2799:
-----------------------------------
Tester: Tibor Zimányi
> DMN Optimize DT parameter binding for compilation
> -------------------------------------------------
>
> Key: DROOLS-2799
> URL: https://issues.jboss.org/browse/DROOLS-2799
> Project: Drools
> Issue Type: Enhancement
> Components: dmn engine
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
> Attachments: AFTER.png, BEFORE.png
>
>
> Currently, DMN layer Evaluator method:
> {code:java}
> org.kie.dmn.core.ast.DMNDTExpressionEvaluator.evaluate(org.kie.dmn.api.core.event.DMNRuntimeEventManager, org.kie.dmn.api.core.DMNResult)
> {code}
> calls down to FEEL layer function:
> {code:java}
> org.kie.dmn.feel.runtime.functions.DTInvokerFunction.invoke(org.kie.dmn.feel.lang.EvaluationContext, java.lang.Object[ ])
> {code}
> In order to evaluate Decision Table using DecisionTableImpl.
> Currently, the whole Decision Table FEEL expression/UT are compiled to CompiledExpression and this enable for fast performance during execution and multiple evaluation, however, the parameter binding for the invocation from the DMN layer does not leverage FEEL expression compilation of the parameters ( information/knowledge requirements coming from the DRG graph ) hence the parameter binding is not really as fast as it could be across several evaluation.
> The current proposal leverage compilation for the parameter (names) which are actually FEEL expression, in order to move from this scenario:
> !BEFORE.png!
> to this:
> !AFTER.png!
> Conclusion the current proposal optimize the DMN parameter binding for the Decision Table invocation by an order of magnitude*
> {{*}} if compared to baseline, using a JUnit test part of the actual code base as benchmark
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (DROOLS-2799) DMN Optimize DT parameter binding for compilation
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2799?page=com.atlassian.jira.plugi... ]
Matteo Mortari updated DROOLS-2799:
-----------------------------------
Description:
Currently, DMN layer Evaluator method:
{code:java}
org.kie.dmn.core.ast.DMNDTExpressionEvaluator.evaluate(org.kie.dmn.api.core.event.DMNRuntimeEventManager, org.kie.dmn.api.core.DMNResult)
{code}
calls down to FEEL layer function:
{code:java}
org.kie.dmn.feel.runtime.functions.DTInvokerFunction.invoke(org.kie.dmn.feel.lang.EvaluationContext, java.lang.Object[ ])
{code}
In order to evaluate Decision Table using DecisionTableImpl.
Currently, the whole Decision Table FEEL expression/UT are compiled to CompiledExpression and this enable for fast performance during execution and multiple evaluation, however, the parameter binding for the invocation from the DMN layer does not leverage FEEL expression compilation of the parameters ( information/knowledge requirements coming from the DRG graph ) hence the parameter binding is not really as fast as it could be across several evaluation.
The current proposal leverage compilation for the parameter (names) which are actually FEEL expression, in order to move from this scenario:
!BEFORE.png!
to this:
!AFTER.png!
Conclusion the current proposal optimize the DMN parameter binding for the Decision Table invocation by at least an order of magnitude*
{{*}} if compared to baseline, using a JUnit test part of the actual code base as benchmark
was:
Currently, DMN layer Evaluator method:
{code:java}
org.kie.dmn.core.ast.DMNDTExpressionEvaluator.evaluate(org.kie.dmn.api.core.event.DMNRuntimeEventManager, org.kie.dmn.api.core.DMNResult)
{code}
calls down to FEEL layer function:
{code:java}
org.kie.dmn.feel.runtime.functions.DTInvokerFunction.invoke(org.kie.dmn.feel.lang.EvaluationContext, java.lang.Object[ ])
{code}
In order to evaluate Decision Table using DecisionTableImpl.
Currently, the whole Decision Table FEEL expression/UT are compiled to CompiledExpression and this enable for fast performance during execution and multiple evaluation, however, the parameter binding for the invocation from the DMN layer does not leverage FEEL expression compilation of the parameters ( information/knowledge requirements coming from the DRG graph ) hence the parameter binding is not really as fast as it could be across several evaluation.
The current proposal leverage compilation for the parameter (names) which are actually FEEL expression, in order to move from this scenario:
!BEFORE.png!
to this:
!AFTER.png!
Conclusion the current proposal optimize the DMN parameter binding for the Decision Table invocation by an order of magnitude*
{{*}} if compared to baseline, using a JUnit test part of the actual code base as benchmark
> DMN Optimize DT parameter binding for compilation
> -------------------------------------------------
>
> Key: DROOLS-2799
> URL: https://issues.jboss.org/browse/DROOLS-2799
> Project: Drools
> Issue Type: Enhancement
> Components: dmn engine
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
> Attachments: AFTER.png, BEFORE.png
>
>
> Currently, DMN layer Evaluator method:
> {code:java}
> org.kie.dmn.core.ast.DMNDTExpressionEvaluator.evaluate(org.kie.dmn.api.core.event.DMNRuntimeEventManager, org.kie.dmn.api.core.DMNResult)
> {code}
> calls down to FEEL layer function:
> {code:java}
> org.kie.dmn.feel.runtime.functions.DTInvokerFunction.invoke(org.kie.dmn.feel.lang.EvaluationContext, java.lang.Object[ ])
> {code}
> In order to evaluate Decision Table using DecisionTableImpl.
> Currently, the whole Decision Table FEEL expression/UT are compiled to CompiledExpression and this enable for fast performance during execution and multiple evaluation, however, the parameter binding for the invocation from the DMN layer does not leverage FEEL expression compilation of the parameters ( information/knowledge requirements coming from the DRG graph ) hence the parameter binding is not really as fast as it could be across several evaluation.
> The current proposal leverage compilation for the parameter (names) which are actually FEEL expression, in order to move from this scenario:
> !BEFORE.png!
> to this:
> !AFTER.png!
> Conclusion the current proposal optimize the DMN parameter binding for the Decision Table invocation by at least an order of magnitude*
> {{*}} if compared to baseline, using a JUnit test part of the actual code base as benchmark
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (DROOLS-2799) DMN Optimize DT parameter binding for compilation
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2799?page=com.atlassian.jira.plugi... ]
Matteo Mortari updated DROOLS-2799:
-----------------------------------
Description:
Currently, DMN layer Evaluator method:
{code:java}
org.kie.dmn.core.ast.DMNDTExpressionEvaluator.evaluate(org.kie.dmn.api.core.event.DMNRuntimeEventManager, org.kie.dmn.api.core.DMNResult)
{code}
calls down to FEEL layer function:
{code:java}
org.kie.dmn.feel.runtime.functions.DTInvokerFunction.invoke(org.kie.dmn.feel.lang.EvaluationContext, java.lang.Object[ ])
{code}
In order to evaluate Decision Table using DecisionTableImpl.
Currently, the whole Decision Table FEEL expression/UT are compiled to CompiledExpression and this enable for fast performance during execution and multiple evaluation, however, the parameter binding for the invocation from the DMN layer does not leverage FEEL expression compilation of the parameters ( information/knowledge requirements coming from the DRG graph ) hence the parameter binding is not really as fast as it could be across several evaluation.
The current proposal leverage compilation for the parameter (names) which are actually FEEL expression, in order to move from this scenario:
!BEFORE.png!
to this:
!AFTER.png!
Conclusion the current proposal optimize the DMN parameter binding for the Decision Table invocation across several evaluations by at least an order of magnitude*
{{*}} if compared to baseline, using a JUnit test part of the actual code base as benchmark
was:
Currently, DMN layer Evaluator method:
{code:java}
org.kie.dmn.core.ast.DMNDTExpressionEvaluator.evaluate(org.kie.dmn.api.core.event.DMNRuntimeEventManager, org.kie.dmn.api.core.DMNResult)
{code}
calls down to FEEL layer function:
{code:java}
org.kie.dmn.feel.runtime.functions.DTInvokerFunction.invoke(org.kie.dmn.feel.lang.EvaluationContext, java.lang.Object[ ])
{code}
In order to evaluate Decision Table using DecisionTableImpl.
Currently, the whole Decision Table FEEL expression/UT are compiled to CompiledExpression and this enable for fast performance during execution and multiple evaluation, however, the parameter binding for the invocation from the DMN layer does not leverage FEEL expression compilation of the parameters ( information/knowledge requirements coming from the DRG graph ) hence the parameter binding is not really as fast as it could be across several evaluation.
The current proposal leverage compilation for the parameter (names) which are actually FEEL expression, in order to move from this scenario:
!BEFORE.png!
to this:
!AFTER.png!
Conclusion the current proposal optimize the DMN parameter binding for the Decision Table invocation by at least an order of magnitude*
{{*}} if compared to baseline, using a JUnit test part of the actual code base as benchmark
> DMN Optimize DT parameter binding for compilation
> -------------------------------------------------
>
> Key: DROOLS-2799
> URL: https://issues.jboss.org/browse/DROOLS-2799
> Project: Drools
> Issue Type: Enhancement
> Components: dmn engine
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
> Attachments: AFTER.png, BEFORE.png
>
>
> Currently, DMN layer Evaluator method:
> {code:java}
> org.kie.dmn.core.ast.DMNDTExpressionEvaluator.evaluate(org.kie.dmn.api.core.event.DMNRuntimeEventManager, org.kie.dmn.api.core.DMNResult)
> {code}
> calls down to FEEL layer function:
> {code:java}
> org.kie.dmn.feel.runtime.functions.DTInvokerFunction.invoke(org.kie.dmn.feel.lang.EvaluationContext, java.lang.Object[ ])
> {code}
> In order to evaluate Decision Table using DecisionTableImpl.
> Currently, the whole Decision Table FEEL expression/UT are compiled to CompiledExpression and this enable for fast performance during execution and multiple evaluation, however, the parameter binding for the invocation from the DMN layer does not leverage FEEL expression compilation of the parameters ( information/knowledge requirements coming from the DRG graph ) hence the parameter binding is not really as fast as it could be across several evaluation.
> The current proposal leverage compilation for the parameter (names) which are actually FEEL expression, in order to move from this scenario:
> !BEFORE.png!
> to this:
> !AFTER.png!
> Conclusion the current proposal optimize the DMN parameter binding for the Decision Table invocation across several evaluations by at least an order of magnitude*
> {{*}} if compared to baseline, using a JUnit test part of the actual code base as benchmark
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (DROOLS-2799) DMN Optimize DT parameter binding for compilation
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2799?page=com.atlassian.jira.plugi... ]
Matteo Mortari updated DROOLS-2799:
-----------------------------------
Description:
Currently, DMN layer Evaluator method:
{code:java}
org.kie.dmn.core.ast.DMNDTExpressionEvaluator.evaluate(org.kie.dmn.api.core.event.DMNRuntimeEventManager, org.kie.dmn.api.core.DMNResult)
{code}
calls down to FEEL layer function:
{code:java}
org.kie.dmn.feel.runtime.functions.DTInvokerFunction.invoke(org.kie.dmn.feel.lang.EvaluationContext, java.lang.Object[ ])
{code}
In order to evaluate Decision Table using DecisionTableImpl.
Currently, the whole Decision Table FEEL expression/UT are compiled to CompiledExpression and this enable for fast performance during execution and multiple evaluation, however, the parameter binding for the invocation from the DMN layer does not leverage FEEL expression compilation of the parameters ( information/knowledge requirements coming from the DRG graph ) hence the parameter binding is not really as fast as it could be across several evaluation.
The current proposal leverage compilation for the parameter (names) which are actually FEEL expression, in order to move from this scenario:
!BEFORE.png!
to this:
!AFTER.png!
Conclusion the current proposal optimize the DMN parameter binding for the Decision Table invocation by an order of magnitude*
{{*}} if compared to baseline, using a JUnit test part of the actual code base as benchmark
was:
Currently, DMN layer Evaluator method:
{code:java}
org.kie.dmn.core.ast.DMNDTExpressionEvaluator.evaluate(org.kie.dmn.api.core.event.DMNRuntimeEventManager, org.kie.dmn.api.core.DMNResult)
{code}
calls down to FEEL layer function:
{code:java}
org.kie.dmn.feel.runtime.functions.DTInvokerFunction.invoke(org.kie.dmn.feel.lang.EvaluationContext, java.lang.Object[ ])
{code}
In order to evaluate Decision Table using DecisionTableImpl.
Currently, the whole Decision Table FEEL expression/UT are compiled to CompiledExpression and this enable for fast performance during execution and multiple evaluation, however, the parameter binding for the invocation from the DMN layer does not leverage FEEL expression compilation of the parameters ( information/knowledge requirements coming from the DRG graph ) hence the parameter binding slow down across several evaluation.
The current proposal leverage compilation for the parameter (names) which are actually FEEL expression, in order to move from this scenario:
!BEFORE.png!
to this:
!AFTER.png!
Conclusion the current proposal optimize the DMN parameter binding for the Decision Table invocation by an order of magnitude*
{{*}} if compared to baseline, using a JUnit test part of the actual code base as benchmark
> DMN Optimize DT parameter binding for compilation
> -------------------------------------------------
>
> Key: DROOLS-2799
> URL: https://issues.jboss.org/browse/DROOLS-2799
> Project: Drools
> Issue Type: Enhancement
> Components: dmn engine
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
> Attachments: AFTER.png, BEFORE.png
>
>
> Currently, DMN layer Evaluator method:
> {code:java}
> org.kie.dmn.core.ast.DMNDTExpressionEvaluator.evaluate(org.kie.dmn.api.core.event.DMNRuntimeEventManager, org.kie.dmn.api.core.DMNResult)
> {code}
> calls down to FEEL layer function:
> {code:java}
> org.kie.dmn.feel.runtime.functions.DTInvokerFunction.invoke(org.kie.dmn.feel.lang.EvaluationContext, java.lang.Object[ ])
> {code}
> In order to evaluate Decision Table using DecisionTableImpl.
> Currently, the whole Decision Table FEEL expression/UT are compiled to CompiledExpression and this enable for fast performance during execution and multiple evaluation, however, the parameter binding for the invocation from the DMN layer does not leverage FEEL expression compilation of the parameters ( information/knowledge requirements coming from the DRG graph ) hence the parameter binding is not really as fast as it could be across several evaluation.
> The current proposal leverage compilation for the parameter (names) which are actually FEEL expression, in order to move from this scenario:
> !BEFORE.png!
> to this:
> !AFTER.png!
> Conclusion the current proposal optimize the DMN parameter binding for the Decision Table invocation by an order of magnitude*
> {{*}} if compared to baseline, using a JUnit test part of the actual code base as benchmark
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (DROOLS-2799) DMN Optimize DT parameter binding for compilation
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2799?page=com.atlassian.jira.plugi... ]
Matteo Mortari updated DROOLS-2799:
-----------------------------------
Description:
Currently, DMN layer Evaluator method:
{code:java}
org.kie.dmn.core.ast.DMNDTExpressionEvaluator.evaluate(org.kie.dmn.api.core.event.DMNRuntimeEventManager, org.kie.dmn.api.core.DMNResult)
{code}
calls down to FEEL layer function:
{code:java}
org.kie.dmn.feel.runtime.functions.DTInvokerFunction.invoke(org.kie.dmn.feel.lang.EvaluationContext, java.lang.Object[ ])
{code}
In order to evaluate Decision Table using DecisionTableImpl.
Currently, the whole Decision Table FEEL expression/UT are compiled to CompiledExpression and this enable for fast performance during execution and multiple evaluation, however, the parameter binding for the invocation from the DMN layer does not leverage FEEL expression compilation of the parameters ( information/knowledge requirements coming from the DRG graph ) hence the parameter binding slow down across several evaluation.
The current proposal leverage compilation for the parameter (names) which are actually FEEL expression, in order to move from this scenario:
!BEFORE.png!
to this:
!AFTER.png!
Conclusion the current proposal optimize the DMN parameter binding for the Decision Table invocation by an order of magnitude*
{{*}} if compared to baseline, using a JUnit test part of the actual code base as benchmark
was:
Currently, DMN layer Evaluator method:
{code:java}
org.kie.dmn.core.ast.DMNDTExpressionEvaluator.evaluate(org.kie.dmn.api.core.event.DMNRuntimeEventManager, org.kie.dmn.api.core.DMNResult)
{code}
calls down to FEEL layer function:
{code:java}
org.kie.dmn.feel.runtime.functions.DTInvokerFunction.invoke(org.kie.dmn.feel.lang.EvaluationContext, java.lang.Object[ ])
{code}
In order to evaluate Decision Table using DecisionTableImpl.
Currently, the whole Decision Table FEEL expression/UT are compiled to CompiledExpression and this enable for fast performance during execution and multiple evaluation, however, the parameter binding for the invocation from the DMN layer does not leverage FEEL expression compilation of the parameters ( information/knowledge requirements coming from the DRG graph ) hence the parameter binding slow down across several evaluation.
The current proposal leverage compilation for the parameter (names) which are actually FEEL expression, in order to move from this scenario:
!BEFORE.png!
to this:
!AFTER.png!
Conclusion the current proposal optimize the DMN parameter binding for the Decision Table invocation by an order of magnitude*
* if compared to baseline, using a JUnit test part of the actual code base as benchmark
> DMN Optimize DT parameter binding for compilation
> -------------------------------------------------
>
> Key: DROOLS-2799
> URL: https://issues.jboss.org/browse/DROOLS-2799
> Project: Drools
> Issue Type: Enhancement
> Components: dmn engine
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
> Attachments: AFTER.png, BEFORE.png
>
>
> Currently, DMN layer Evaluator method:
> {code:java}
> org.kie.dmn.core.ast.DMNDTExpressionEvaluator.evaluate(org.kie.dmn.api.core.event.DMNRuntimeEventManager, org.kie.dmn.api.core.DMNResult)
> {code}
> calls down to FEEL layer function:
> {code:java}
> org.kie.dmn.feel.runtime.functions.DTInvokerFunction.invoke(org.kie.dmn.feel.lang.EvaluationContext, java.lang.Object[ ])
> {code}
> In order to evaluate Decision Table using DecisionTableImpl.
> Currently, the whole Decision Table FEEL expression/UT are compiled to CompiledExpression and this enable for fast performance during execution and multiple evaluation, however, the parameter binding for the invocation from the DMN layer does not leverage FEEL expression compilation of the parameters ( information/knowledge requirements coming from the DRG graph ) hence the parameter binding slow down across several evaluation.
> The current proposal leverage compilation for the parameter (names) which are actually FEEL expression, in order to move from this scenario:
> !BEFORE.png!
> to this:
> !AFTER.png!
> Conclusion the current proposal optimize the DMN parameter binding for the Decision Table invocation by an order of magnitude*
> {{*}} if compared to baseline, using a JUnit test part of the actual code base as benchmark
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (DROOLS-2799) DMN Optimize DT parameter binding for compilation
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2799?page=com.atlassian.jira.plugi... ]
Matteo Mortari updated DROOLS-2799:
-----------------------------------
Description:
Currently, DMN layer Evaluator method:
{code:java}
org.kie.dmn.core.ast.DMNDTExpressionEvaluator.evaluate(org.kie.dmn.api.core.event.DMNRuntimeEventManager, org.kie.dmn.api.core.DMNResult)
{code}
calls down to FEEL layer function:
{code:java}
org.kie.dmn.feel.runtime.functions.DTInvokerFunction.invoke(org.kie.dmn.feel.lang.EvaluationContext, java.lang.Object[ ])
{code}
In order to evaluate Decision Table using DecisionTableImpl.
Currently, the whole Decision Table FEEL expression/UT are compiled to CompiledExpression and this enable for fast performance during execution and multiple evaluation, however, the parameter binding for the invocation from the DMN layer does not leverage FEEL expression compilation of the parameters ( information/knowledge requirements coming from the DRG graph ) hence the parameter binding slow down across several evaluation.
The current proposal leverage compilation for the parameter (names) which are actually FEEL expression, in order to move from this scenario:
!BEFORE.png!
to this:
!AFTER.png!
Conclusion the current proposal optimize the DMN parameter binding for the Decision Table invocation by an order of magnitude*
* if compared to baseline, using a JUnit test part of the actual code base as benchmark
was:
Currently, DMN layer Evaluator method:
{code:java}
org.kie.dmn.core.ast.DMNDTExpressionEvaluator.evaluate(org.kie.dmn.api.core.event.DMNRuntimeEventManager, org.kie.dmn.api.core.DMNResult)
{code}
calls down to FEEL layer function:
{code:java}
org.kie.dmn.feel.runtime.functions.DTInvokerFunction.invoke(org.kie.dmn.feel.lang.EvaluationContext, java.lang.Object[ ])
{code}
In order to evaluate Decision Table using DecisionTableImpl.
Currently, the whole Decision Table FEEL expression/UT are compiled to CompiledExpression and this enable for fast performance during execution and multiple evaluation, however, the parameter binding for the invocation from the DMN layer does not leverage FEEL expression compilation of the parameters ( information/knowledge requirements coming from the DRG graph ) hence the parameter binding slow down across several evaluation.
The current proposal leverage compilation for the parameter (names) which are actually FEEL expression, in order to move from this scenario:
!BEFORE.png!
to this:
!AFTER.png!
> DMN Optimize DT parameter binding for compilation
> -------------------------------------------------
>
> Key: DROOLS-2799
> URL: https://issues.jboss.org/browse/DROOLS-2799
> Project: Drools
> Issue Type: Enhancement
> Components: dmn engine
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
> Attachments: AFTER.png, BEFORE.png
>
>
> Currently, DMN layer Evaluator method:
> {code:java}
> org.kie.dmn.core.ast.DMNDTExpressionEvaluator.evaluate(org.kie.dmn.api.core.event.DMNRuntimeEventManager, org.kie.dmn.api.core.DMNResult)
> {code}
> calls down to FEEL layer function:
> {code:java}
> org.kie.dmn.feel.runtime.functions.DTInvokerFunction.invoke(org.kie.dmn.feel.lang.EvaluationContext, java.lang.Object[ ])
> {code}
> In order to evaluate Decision Table using DecisionTableImpl.
> Currently, the whole Decision Table FEEL expression/UT are compiled to CompiledExpression and this enable for fast performance during execution and multiple evaluation, however, the parameter binding for the invocation from the DMN layer does not leverage FEEL expression compilation of the parameters ( information/knowledge requirements coming from the DRG graph ) hence the parameter binding slow down across several evaluation.
> The current proposal leverage compilation for the parameter (names) which are actually FEEL expression, in order to move from this scenario:
> !BEFORE.png!
> to this:
> !AFTER.png!
> Conclusion the current proposal optimize the DMN parameter binding for the Decision Table invocation by an order of magnitude*
> * if compared to baseline, using a JUnit test part of the actual code base as benchmark
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month