BreakPoint
Rube Goldberg Code
@crossrulz wrote:
Darren's Weekly Nugget 10/26/2009
I'm probably getting way off topic here, but...
In that Nugget, Darren issued the following challenge:
No, it's not a subVI...it's a built-in function. If it were a subVI you wouldn't be able to wire any arbitrary 2D array to it. Not to mention subVI call overhead. And the allocation of an array for the Array Size output. I welcome somebody to post some benchmark results comparing the two approaches...I think you'll find Matrix Size to be faster, although I will admit that there probably aren't too many use cases that require extremely performant row/column calculations...
"Ha!" I thought to myself. "Silly 2009 Darren couldn't see into the future and so he had no idea about malliable VIs. I can too wire an arbitrary 2D array into a subVI". And since nobody accepted his challenge in 2009, here we are. I was curious and did the test with a malliable VI.
Matrix Size is still noticeably faster. Interestingly enough, enabling iteration parallelism brought them much closer to identical, even for higher number of iterations.
So, take that past Darren who was unable to see into the future: You were only a partially right!
I've been burned a few times by vims...
At some point I wasted 4 hours because an exe wouldn't build anymore. I had to remove 50%, remove the other 50%, iterate, narrowed it down to a few VIs, remove 50% of the VIs, etc.
The simples vim ever (Synchronize Data Flow.vim) was the cause.
"Heavy" vims tend to introduce a noticeable to unworkable delay, especially when they change, or IIRC even when opened and closed.
Search LabVIEW like a graph! 
wiebe@CARYA wrote:
I've been burned a few times by vims...
At some point I wasted 4 hours because an exe wouldn't build anymore. I had to remove 50%, remove the other 50%, iterate, narrowed it down to a few VIs, remove 50% of the VIs, etc.
The simples vim ever (Synchronize Data Flow.vim) was the cause.
"Heavy" vims tend to introduce a noticeable to unworkable delay, especially when they change, or IIRC even when opened and closed.
Haver had similar issues. Also, files that use vims may get broken if the vim is changed and need to be force-recompiled or that the vim is manually reconnected again to force a recompile. Sometimes I also get broken wires to the vim but a runnable VI. And if I try to minimize the code to post a bug report, the problem goes away.
wiebe@CARYA wrote:
The array to cluster + unbundle has the advantage of being 'vertically friendly'.
I'd say a Get Matrix Size saves you a couple of blocks.:)
