Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Re: unbundle efficiency?

87 views
Skip to first unread message

altenbach

unread,
Jun 1, 2005, 9:10:57 PM6/1/05
to
<blockquote><hr>XCoop wrote:<br>what if any speed/memory penalty is paid by unbundling in a loop as opposed to unbundling outside the loop and wiring directly to the edge? I have a subvi which I pass a cluster containing scalars and arrays, This subvi is called many times during execution and is only read not written to. For my sanity I would prefer to unbundle in the loop if the time penalty is severe. Any advice from the experts?<br><hr></blockquote><br>Xcoop<br>The main reason I did not come up with a mode definite answer is the fact that I don't quite understand your description. Is the subVI inside the loop or is the loop inside the subVI? ;) If the loop is inside the subVI, how many times does the loop run for each subVI call? How big are the arrays in the cluster? Could you attach a simplified example? <br><br><blockquote><hr>Raghunathan wrote:<br>Why not use local variables ? Accepted that you will be making a copy of the data, but I still feel that it is much better ( and simpler ) to just unbundle once outside the loop, load the data into local variables and read from these variables wherever there is a need.<hr></blockquote><br>Raghunathan<br>This suggestion makes very little sense to me. I possibly agree with the "unbundle once outside the loop", but why do we need to "load it into a local variables"? Much easier would be to unbundle once outside the loop and wire from there to the nodes that need them. Why would you take a detour via locals if it is already <i>loaded into a wire</i> ;)??? Could you clarify what you meant?

XCoop

unread,
Jun 1, 2005, 10:41:07 PM6/1/05
to
altenbach,<br><br>my apologies for the incomplete description..I will try again with slightly more background...<br><br>This program is part of some image processing vi's I've written to process Laser Induced Fluorescent Pictures I have acquired. (I am full time in fluid dynamics research --->only part time LV wirer :-), so give me a little slack on the LabView Speak -heh) <br><br>The Picture Image is converted to a 2D Array and is indexed to every pixel location via a double nested loop. 2D Array size is 1016 x 1000, so a little over a million cycles total. The subvi is inside the doublenested loop and is called each cycle. To clear up some of the clutter from excessive terminals, I would like to pass the subvi a cluster containing all parameters needed for execution. This particular cluster has ten elements of which eight are scalars and two are 1D arrays (1D array lengths are 1016 and 1000 long respectively)<br><br>My option is:<br>1)Unbundle the cluster outside the double nested loop and wire directly to 10 terminals, OR<br><br>2) Pass the whole bundle to the subVI itself and unbundle it inside the subVI (1Million+ times)<br><br>I guess my question is driving at how LV interprets this when it compiles. Is there a difference? Hopefully I have done a better job of explaining :)<br><br>Also:<br>I have been bitten by local variables once before and now only use them in case selects to cut down on duplicate indicators and controls on the front panel, UNLESS I am 100% sure of the execution order. <br><br>Thanks Again

Kevin Price

unread,
Jun 2, 2005, 11:10:56 AM6/2/05
to
XCoop,<br><br>When you unbundle an array from the cluster, the array is copied and you risk a relatively slow memory allocation operation. At minimum, I'd advise unbundling the arrays outside the loop and passing them in as separate parameters. Here are a couple other thoughts:<br><br>1. It sounds like your cluster remains constant throughout the 1016x1000 subvi calls, right? Couldn't you put the two loops <b>inside</b> the subvi? Then you'd only have overhead from one function call, not a million. Plus you could unbundle everything inside the subvi but outside the loops for further efficiency.<br><br>2. Consider setting up the subvi as a subroutine (VI Properties-->Execution). This reduces overhead, but beware -- it is also less friendly about yielding the CPU.<br><br>As for very general advice: Arrays in clusters get copied when unbundled. Calls to subvi's have overhead. Squeezing out an extra 10% performance isn't always worth the resulting time, effort, and the long-term hassle of code inelegance. But when you <i>really</i> need that last 10%, be sure to listen to <i>altenbach</i>.<br><br>-Kevin P.

DFGray

unread,
Jun 3, 2005, 9:11:01 AM6/3/05
to
A subVI will always cost you more in time than a flat diagram, although that overhead is usually pretty small. Only you can make the tradeoff between maintainability and speed. If you care about it, you should benchmark several variations and find the best - it is not always obvious.<br><br>One of the reasons you are having trouble finding information on how data is passed in LabVIEW is that it is extremely complex and changes from LabVIEW version to LabVIEW version, so tends to not be documented. Since LabVIEW does memory managing for you, it tries to be smart about how it does it. This has improved dramatically in the last few versions. The newer your version of LabVIEW, the better off you are. This is especially true for clusters. In LV6.0, unbundling a cluster caused a copy. In LV7.1, a copy will only be made if necessary to ensure data integrity. Once again, the gold standard is benchmarking your application and modifying it until it is good enough.<br><br>One final comment on locals for readers of this thread. Use of locals is a guaranteed way to slow down your program. Reading a local requires a trip through the UI thread and a copy of the data. Reading a wire or unbundling and reading is simply pulling a value from memory. The difference in speed is somewhere around one or two orders of magnitude (yes, I did mean 10 to 100) and could be more. I haven't benchmarked it lately. You have already been bit by race conditions using locals, so I won't flog that dead horse.
0 new messages