Nested IPE (In Place Element) usage when accessing Cluster/Array data via DVR

Question

I am sharing data across several VIs and loops via a DVR, and accessing the data via a DVR IPE. The data is a cluster of arrays. The diagram below (VI attached) illustrates the structures invloved, but not the structure of the application.
(The diagram above does not include initialization of the arrays, as it is intended only to illustrate the Cluster1 data type. Array lengths could be 100.)
The DVR (DVR1) is passed to multiple VIs of the application at startup.
Each VI executes loops that either read or write particular elements of each array (fArray1 or fArray2).
I believe the DVR IPE (B1-DVR) provides blocking so that only one task can modify the data (Cluster1) at any time.
Case 1 illustrates how I currently WRITE to array elements. The outer IPE (block B1) is rolled into a VI (not shown) that takes DVR1, Index, and Value as inputs.
Cases 2 - 4 illustrate 3 additional methods that remove one or both of the inner IPEs (B2-Cluster and B3-Array).
Case 2: IPE B3 (Array Index/Replace Elements) is replaced with a non-IPE 'Replace Array Subset'.'
Case 3: IPE B2 (Unbundle / Bundle Elemnts)' is replaced with a non-IPE cluster 'Unbundle'/'Bundle'.
Case 4: removes both B2 and B3.
I implemented case 1 a long time ago.  When I had to do the same thing again recently, I did case 4.  When I stumbled across my earlier implementation, I was a bit suprised
Which of the 4 cases should take the least time (or resources) to execute? I think case 4 has as few array allocations as any of the other 3.
The attached image did not capture the Buffer Allocation marks, so I marked the ones that differed with a red "B".
I am only interested in differences in how the arrays are handled, so I see no signioficant differences.
Is this one of those cases where LV doesn't need my help?
Incidently, I recently wrote a small app with shared data and decided to try FGVs to share array data.  For small arrays, 10^7 iterations, and an FGV based array-element read followed by a element write, the FGV was faster.  1.2us per read/write for FGV vs 3us per r/w for an DVR/IPE based read/write (like above).
Peter
LV 2011 SP1, Windows 7 64-Bit
Attachments:
IPE.vi ‏9 KB

Answer 1

Option 1 is a definite no and as far as I know it has been NI's explicit intention to steer clear from it. I believe there's an idea in the IE which asks for this.
I agree that option 2 makes sense, but I don't think it should be something the user specifies. Either LV can detect it automatically or it can't, but I doubt NI would let you have an option which creates the possibility for this kind of bug.
I'm not sure, but the mark as modifier option on the IPES might be the option you're looking for. I know that it exists and I know very roughly what it does, but the documentation for it is very limited and I never actually played around with it, as usually I don't need these kinds of optimizations.
You may well be right that a new option on the IPES is desirable and you should probably add it to the idea exchange.
As for NIWeek, I'm not going this year, so I have no idea what kinds of sessions are around, but it's a great place to find people who know what they're talking about and ask them about it directly. Certain people in LV R&D would probably be ideal for this and if you ask relevant people, you might even get their names. I'm sure buying them a beer would also help to loosen their tounges. If you ask me, this type of interaction is the main value of the conference, not the sessions themselves.
Try to take over the world!