Skip to main content
September 19, 2024
Solved

Strange Local Variable Performance

  • September 19, 2024
  • 12 replies
  • 0 views

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,

Best answer by stefanhelzle0001

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.

12 replies

mikes0011
Brainy
September 20, 2024

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.

jackf0001Author
September 20, 2024

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. 

stefanhelzle0001
Brainy
September 20, 2024

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.

jackf0001Author
September 20, 2024

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)

mikes0011
Brainy
September 20, 2024
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.