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
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.
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.
Just curious, what's the overall performance of the interface? I don't know if you have other stuff in the interface or not, but if you isolate it to just these two variables is the interface taking 2 seconds to load or 1?
Peter Lewis This interface is pretty large, but I was able to comment out everything but these two variables and a couple other local variables they depend on. When I tested the interface the total evaluation time is 1,457ms and each of the local variables is 1,325ms. I have attached a screenshot of the performance results below.
I guess that would be a good indication that Mike is correct in saying what he said earlier (quoted below), and local!dataCapture is not actually taking as long to evaluate as the performance evaluation is indicating.
Mike Schmitt said: 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