cluster array performance penalty

[Ben]

Travis wrote "and like we saw before 8.2 is much slower (and, yes, I do agree that this is a problem)."

I do not have the time to review your examples so I will trust you.

If however this get demoted to a non-bug, let me know and I will try to help out!

Thank you,

Ben

[AnthonV]

I was following this thread with great interest as I am having similar issues and have to use the 'show buffer allocations' feature every 5 mins to ensure my code runs efficiently. 

My question is:  Travis, what was the outcome of this and am I safe using 8.2.1 or should I wait for the next version to be released?

Message Edited by Support on 06-22-2007 08:42 AM

[Travis_M.]

Hello Ben et. al.,

As promised, I’ll give you an update on this issue.  I’m not sure if anyone has had a chance to try this out in 8.5, but this behavior has not changed.  The issue was recognized as a performance problem, but unfortunately we decided not to fix it.  The reason that this was not fixed is that this problem does not affect data or data integrity, a relatively painless workaround is available, and in LabVIEW 8.5 we have introduced a new structure completely designed to take this guesswork out of managing low level performance considerations (the In Place Element Structure).  I know this isn’t an answer people may like to hear, but I am confident that once you start using the new memory management techniques you’ll really love having the ability to explicitly tell LabVIEW how to manage your resources. 

Thanks for all those that have been following this thread!

[Ben]

HI Travis M!

Well since I have your attention....

Figure 1 (of your link) claims that it will operate in-place. If it did, the array constant on the diagram would change.

Next:

I am looking forward to using the new construct when I finally to get to use LV 8.5 ( Although I Beta tested, I have had to work with existing apps).

Next:

What we really need out of this discusion is a white paper on the "in-placeness" algorithm so we can predict when when the new inplace element structure should be used. Contrary to the suggestion in the KB you posted, I can not wait until after the fact to figure out when to use it. My customers have this bad habit of sueing us if it does not work perfect the first time. 

Seriously, we could really use more info on predicting buffer re-use. We have been doing this "swing the dead cat around in the moonlight" (code and look for buffer dots) stuff too long. Can we turn this back into a science?

Ben

[AnthonV]

I have several cases in my code where this new construct will remove the need to scrutinise 'Show buffer allocations' so I have to say Thank You for this new feature.  However, there are still other cases where (in my opinion) non-intuitive decisions are being made by the compiler - I will have to test them all in 8.5 before raising them again here.

Will the in-place construct also allow one to wire large datastructures or arrays into (and the same (but modified) structure out of) sub-vi's without the compiler making a copy at the entrance to the VI?  This will allow me to clean up a lot of flattened code that I have had to create to avoid the use of sub-vi's and buffer allocations.

Anthon

[tst]

---

@AnthonV wrote:

Will the in-place construct also allow one to wire large datastructures or arrays into (and the same (but modified) structure out of) sub-vi's without the compiler making a copy at the entrance to the VI?

---

The compiler should not make a copy if there are no forks in the wire and if it can determine an inplaceness path through the VI. That should work in old version as well.

One of the things Steve Rogers said in his session was that you can use this structure (like you can use a shift register) to force an input and an output of a subVI to use the same buffer, so that should theoretically help if you don't split the wire in the caller and if you don't have too complicated nesting of structures in your subVI.

[Travis_M.]

Thanks tst for the reply, and to the others helping us improve the product through feedback.

It seems there are two questions:

1)    Why does the constant not change if the operation is inplace?
2)    Can we document performance behavior so that we can accurately predict buffer reuse?

to address these questions:

1) Ben, I'm not quite sure I follow your claim.  Constants on the diagram should never change.  This is because there is a separate copy of the data for display on the diagram and on the panel (when they are visible).  This is why we say don't put large array indicators on a visible panel unless you really need to see the data.  A copy is made for the UI.

2) I agree that we should document as much as we can about our optimization algorithms so that people that are really concerned with those matters have the ability to program with the rules in mind.  We do document both constant-folding algorithms and our inplaceness algorithms.  The inplaceness documentation can probably be expanded, but it can be found in the LabVIEW Help: Fundamentals->Managing Performance and Memory->VI Memory Usage.   In reviewing some of this documentation, I found this section:

Yeah, it looks like the help says it is the optimal solution, but in practice it looks like to be optimal in all cases, you’ll need to wire through all the other items in the cluster….   Also, I know that sometimes connecting controls/indicators to the pane can have an impact on whether or not our algorithm can optimize memory.  I filed a CAR (ID 4C9CTF3A) to change those things in our documentation.

Message Edited by Travis M. on 08-10-2007 02:04 PM

[Ben]

HI Travis,

I appreciate you trying but maybe I need a little help understanding.

Refer to the image and code I posted earlier in post #11.

"Method 2" is of the same form as you image.

"method 3" is theorectically the same but is a lot faster.

Were can I find that in the existing documentation?

I agree the constant on the diagram should not change. What I was suggesting was that the example shown in the in-placeness article is not operating in the memory space that holds the constant from the diagram but rather in a buffer that was created from the buffer hold the constant. A better example would have used a shift register since the data in the SR does not have to be copied to be acted on.

Ben

[Travis_M.]

Hello Ben,

Agreed – the example using a shift register would be better because it wouldn’t have a copy for the UI.  Although, an extra copy for the UI is only necessary if the controls are visible which is the topic of another topic in this article.  I think for the purposes of illustration of the “magic pattern” the screenshot does a good job except for the important point made earlier in this post.  It’s not always so magic, and in the example created and CARed for this forum, the magic pattern required the “through wiring” of all the nodes in the cluster.  Because this is kind of a quirk in our algorithm it is not in the documentation (but I have requested that it be changed).

Hope that helps clarify-

[Ben]

Kudos to you Travis for putting up with me!

Here have some stars.

Ben