Programmatically create array from common cluster items inside array of clusters

Question

I have seen many questions and responses on dealing with arrays of clusters, but none that discuss quite what I am looking for. I am trying to programmatically create an array from common cluster items inside array of clusters. I have a working solution but looking for a cleaner approach.  I have an array of clusters representing channels of data.  Each cluster contains a mixture of control data types, i.e.. names, types, range, values, units, etc. The entire cluster is a typedef made up of other typedefs such as the type, range and units and native controls like numeric and boolean. One array is a “block” or module. One cluster is a channel of data. I wrote a small vi to extract all the data with the same units and “pipe” them into another array so that I can process all the data from all the channels of the same units together.  It consists of a loop to iterate through the array, in which there is an unbundle by name and a case structure with a case for each unit.  Within a specific case, there is a build array for that unit and all the other non-relevant shift registers pass through.  As you can see from the attached snapshots, the effort to add an additional unit grows as each non-relevant case must be wired through.  It is important to note that there is no default case.  My question:  Is there a cleaner, more efficient and elegant way to do this?
Thanks in advance!
Solved!
Go to Solution.
Attachments:
NI_Chan units to array_1.png ‏35 KB
NI_Chan units to array_2.png ‏50 KB

Answer 1

nathand wrote:
Your comments made me curious, so I put together a quick test. Maybe there's an error in the code (below as a snippet, and attached as a VI) or maybe it's been fixed in LabVIEW 2013, but I'm consistently getting faster times from the IPE (2-3 ms versus 5-6ms for unbundle/index). See if you get the same results. For fun I flipped the order of the test and got the same results (this is why the snippet and the VI execute the tests in opposite order).
This seems like a poster child for using the IPES!  We can look at the index array + replace subset and recognize that it is in place, but the compiler is not so clever (yet!).  The bundle/unbundle is a well-known "magic pattern" so it should be roughly equivalent to the IPES, with a tiny penalty due to overhead.
Replace only the array operation with an IPES and leave the bundle/unbundle alone and I wager the times will be roughly the same as using the nested IPES.  Maybe even a slight lean toward the magic pattern now if I recall correctly.
If you instantly recognize all combinations which the compiler will optimize and not optimize, or you want to exhaustively benchmark all of your code then pick and choose between the two to avoid the slight overhead.  Otherwise I think the IPES looks better, at best works MUCH better, and at worst works ever-so-slightly worse.  And as a not-so-gentle reminder to all:  if you really care about performance at this level of detail: TURN OFF DEBUGGING!