I have been working on improving the performance of my interface, and I came across some performance results that I don't understand. I have a local variable (local!initialData) that calls an expression rule. I have a second local variable (local!dataCapture) that is just a copy of local!initialData. Looking in the performance tab of the interface, both of these local variables take the exact same amount of time to evaluate (+/- 1ms). However, I would expect local!initialData to take longer than local!dataCapture since local!dataCapture is just copying the data from local!initialData, not running the expression rule.
Can anyone explain this to me? Is this to be expected, or am I doing something wrong to cause this to happen?
I have attached an image of the performance numbers for these two local variables and have included the definitions of both below.
Thanks in advance!
local!initialData: a!forEach( local!orderLineData, rule!SSTH_initialData( orderLineData: local!orderLineData, index: fv!index, desiredOutput: "dataCapture" ) ), local!dataCapture: local!initialData,
Discussion posts and replies are publicly visible
Is the data being loaded into local!dataCapture a bit bulky? That could explain why the copy is also taking some time. Beyond that, just remember that execution times can be a bit random between different runs of the rule.
I see a few other things I would do different, but there is nothing wrong with that code snippet.
It could be that the second local wants to evaluate, but has to wait for the first one to complete. This would explain the one millisecond difference. But this is more guesswork than deep knowledge.
Yes, the data being copied into local!dataCapture can be fairly large.
The execution time of the rule does vary for each run, however local!dataCapture and local!initialData always take almost exactly the same amount of time.
That could make sense, as local!dataCapture always seems to be 1-3% higher than local!initialData, even if the time is the same. I tried moving local!dataCapture down in the code a little, just to see what would happen (there is now another call to that rule in between local!initialData and local!dataCapture), and local!initialData is now taking a few ms longer than local!dataCapture. This seems like a good indication that your guess is correct, as the rule now has a few more ms to evaluate before local!dataCapture tries to evaluate.
I also tried copying the expression from local!initialData into local!dataCapture (so it evaluates the same rule twice). This seems to have uncoupled the two variables, further indicating that your guess may be correct.
Out of curiosity, what do you see that you would do differently? I'm always open to suggestions (especially ones to improve performance as 1,000+ ms is definitely not ideal)
Jack Ferguson said:Out of curiosity, what do you see that you would do differently
Honestly, this might be a case where you need to take the "performance numbers" with a grain of salt. I think Stefan is probably right i.e. the downstream one is showing a similar number only because it's waiting on the prior dependent, i.e. the total time isn't even necessarily the combination of the two numbers, but rather perhaps the intersection, if you get my drift (i.e. it's displaying the same for both but they don't represent the total). It's hard to tell for sure of course.
Some ideas:
- Keyword syntax in the foreach()
- That initialData function gets the whole set of data plus the index instead of just the item. Doing so could reduce computation time.
- Why do you need the same data in two locals?
Stefan Helzle said:Why do you need the same data in two locals?
come on, this is an easy one - there are tons of use cases where you'll store an original version of some variable or data set in order to easily let the form know when any updates have been made, since we aren't really provided any other innate ways of allowing a form to know when edits have been completed ;-)
Sure, but that's the things coming to my mind when looking at that code snippet.
Stefan Helzle said:That initialData function gets the whole set of data plus the index instead of just the item. Doing so could reduce computation time.
I tried moving the a!forEach statement into the initialData rule and I am getting much better performance out of those variables. It did make some other variables take much longer, but I think they just need to be restructured for this new setup. Thanks for the suggestion!
Mike Schmitt said:come on, this is an easy one - there are tons of use cases where you'll store an original version of some variable or data set in order to easily let the form know when any updates have been made, since we aren't really provided any other innate ways of allowing a form to know when edits have been completed ;-)
Yes this is correct, I need to be able to compare the initial data with changes made in the form.