Why is the difference in execution speed of the function "SetCtrlVal" between constant and changing values so small ?

[NissenVW]

In my large application (1 MB exe-file) I am continuously updating a lot of numeric controls with new values. Most of them do not really change their value. Within my search of improving the performance of my application I noticed, that there is only a small difference of the execution speed between a call of "SetCtrlValue" with constant values and calls with changing values. It runs much faster (25 times on my PC), if I get the actual control value with "GetCtrlVal", compare it with my new value an do a call to "SetCtrlVal" only if the current value and the new value are different.

My questions to CVI-developers is:
Isn't it possib
le to do this compare within the function "SetCtrlVal"

My question to all CVI-users is:
Does anyone have similar tips to improve the performance of CVI applications ?

I developed a small test application for this problem, which I can mail to interested users.

[Chris Matthews]

What takes the extra time is the redraw of the control. When you call SetCtrlVal we ALWAYS redraw the control. We wouldn't want to build in functionality to check if the value was the same because that would add additional time to the SetCtrlVal in every case. If you want to do it outside of the loop you can as you have done above. You have a few options. First, keep a previous value variable for the controls that you can use to determine whether to set the control value. I.E.

int oldVal = 0;
int newVal = 0;

if(newVal!=oldVal) {
SetCtrlVal(..., newVal);
oldVal = newVal;
}

Also, if you set the value of a control through SetCtrlAttribute instead, there is no built in redraw of the control (which is what takes all the time). Using SetCtrlAttribute
to set the value is very fast, but remember there isn't a built in redraw on the screen to display the new number.

Best Regards,

Chris Matthews
Measurement Studio Support Manager

[RobertoBozzolo]

What do you mean by 'built in redraw' of the control? What is the real difference between SetCtrlVal and SetCtrlAttribute (...ATTR_CTRL_VAL...): which of them is faster and why? When the control is really updated on the screen?
Roberto

[LuisG]

Roberto,

The difference between SetCtrlVal and ATTR_CTRL_VAL is that the former immediately redraws the control with the new value, after each call to the function. The latter simply marks the control for redraw, which will happen whenever the CVI run-time engine has a chance to process events (after returning from the callback function, or whenever you call ProcessSystemEvents, ProcessDrawEvents, GetUserEvent, etc...)

The implication of this difference is that if you are making consecutive calls to SetCtrlVal, you're better off using ATTR_CTRL_VAL instead, so that a single redraw takes place, instead of one for each function call.

Note: if the control is hidden or overlapped, then the behavior of SetCtrlVal reverts to that of ATTR_CTRL_VAL.


- luis

[NissenVW]

thanks for your answer,
I think the method, you described is the best one. I tried also to use SetCtrlAttribute instead of SetCtrlVal in my test application and found out, that SetCtrlAttribute needs 1 second compared with 0.45 seconds for SetCtrlVal (3000 calls). But why does it take so long, if you make no redraw ?. You can find my test application attached to this comment.

-Rolf Nissen, Volkswagen

[LuisG]

Rolf,

It's a good test that you made, and the results did surprise me. I found that what was happening is that for a simple numeric control (as opposed to a table or a textbox, for example) the drawing doesn't take very much time at all, whereas in the case of ATTR_CTRL_VAL, the required overhead of modifying the control before and after setting its value, so that the drawing does not take place, is overwhelming the speed reduction achieved by avoiding the draw, and in the end it's making it slower.

I should mention that the initial purpose of ATTR_CTRL_VAL was not for its speed benefit, but rather for its behavior of not showing intermediate values. Regardless, I was under the impression that it was also faster, but apparently that's not always
the case 🙂

- luis