 |
|
||||||||||||
Many of us have read the famous "Clear as mud thread" but we never came back an nuggetized it. I reciently wrote an internal memo on the subject and thought it ould serve as a nugget starter.
Conditionally read/written terminals on the connector pane are BAD!
What are they?
This snippet on the left contains two examples of conditionally reached terminals. Array – numeric will not be read of Method is Get and Array – numeric 2 will not be written if Method is Set. Many years ago creating your functional global variables in this manner was considered to be good style however; best practices changed when the LabVIEW community looked at performance.
Better practice is to have all terminals that are wired to the connector pane on the root block diagram as shown on the right.
There is even a high priority VI Analyzer test to catch this. Why? Well, lets benchmark the code above with these benchmark vis and run the VI profile tool.
The utility that you might not recognize is C:\Program Files (x86)\National Instruments\Labview 2011\vi.lib\Utility\High Resolution Relative Seconds.vi, it calls the system precision timer and has a finer resolution than get tick count. It’s not been promoted to the palates because it will not function on an OS that does not have a Precision timer. Most modern machines do.
The results:
Here we can see that using conditionally terminals slightly increases the execution speed of the sub-vi On other hand, this is more than made up for by the callers performance hit! Set-up time for calling the subvi with conditional terminals goes up by orders of magnitude.
TiTou wrote:
So may VIs from the vi.lib have wired terminals in a case structure... Many we should place on idea on the exchange to ask NI to fix all of them!
Nice nugget!
Not so fast there TiTou! One thing I left out of the previous post is just what causes the pain in the caller. With conditionally read terminals the Caller must protect its copy of the data in case there is a breakpoint in the sub-vi (See the clear as mud thread.) Its that data copy/ buffer allocation that slows down the caller. The time penalty is related to the size of the data. In the example above we have a 2D array of a million DBLs read and written 500 times. Re-running with a 1x1 array (essentially a scalar) and 50000 writes/reads yields these results from the profiler.
YUP: the scalar data copy is faster than reading or writing a terminal with a scalar. SO, for very small data sets the wired terminals might be better off in only the case they are used if they are not a "Required" terminal. But I feel it is good practice to design my AE's for large data sets - They allway seem to get large anyway
Ben wrote:
Hi Jeff,
Good topic to Nuggetize!
Could you try three changes to your benchmarking code to see if they ifluence the numbers?
1) Move the Init array to prior to the seq frame to ensue that time is not in the calculation.
2) Use a control instead of a constant to set the array size so LV does not play constant folding tricks on us.
3) Move the output terminal to AFTER the seq so that GUi updates do not enter the measurement.
Again, thank you!
Ben
Your wish is my command!
Additionally Mod 4) Use a control to set itterations was incorporated.
NOTE: That optomizer scares me too sometimes with benchmark code hence, the random array is also generated to keep the compiler from tossing out the whole darned loop. In theory the fact that the AE could be called from another vi should flag the compiler that this may not be loop invarient code but I hate taking chances.
For 500 iterations of 1000x1000
Conditional 8.78697Sec
Unconditional 7.13198Sec
@20% imprrovement for the loop
The delta in time from the original seems to prove that I was correct in assuming that using constants on the Array size allowed the optomizer to compile the array as a constant and did not effect benchmark time.
|
||
|
||
My Profile | Privacy |
Legal |
Contact NI
© 2011 National Instruments Corporation. All rights reserved. |  E-Mail this Page
|
||
|
||