Buffer allocation in functional variable is driving me crazy

[vgravel]

Hello,

I have a functional variable that holds 16 waveforms. Theses waveforms will be growing in time. For more memory efficency, I'm trying to use preallocation of the data arrays (let's say 300000 doubles).

But it looks like there is a new buffer allocation at the shift register and  this is slowing my application big time.

Since i'm pre-allocating and using inplace structure, I don't see why LabVIEW is doing a duplication of all the waveforms. 

Any idea to acheive an efficient functional variable?

Here are the code of my functional variable.

Thanks in advance!

Vincent

[nitad54448]

hi

what is the version you use ? I remember there some bugs in FG using waveforms for 8.6 and prior to that...this might not be the case here, if so, disregard my comment

regrads

[vgravel]

Sorry, I should have mentionned it already... I'm using LabVIEW 2009.

[Hummer1]

Perhaps you need to init the buffer allocation outside the loop and bring it in as an as a prezeroed variable like you are doing inside the init case.  Omit that part of the init and that should do it.  I have taken to initializing all my variables in an init sub vi with typedefed variables so it can be made small on the working screen, but blown up if I need to get to the data.

Hope that helps.

Hummer1 

[Jarrod_S. · Accepted solution]

I don't think that buffer allocation dot is your problem. That will appear on any uninitialized shift register, and is just LV's way of telling you it's going to store data there.

To improve performance I would add a new case called Get Data that outputs the waveform buffer, rather than having the shift register wired directly to an output indicator. That just forces LV to make a copy of the whole buffer every time this FG is called, even just to write or initialize data. The Get Data case would fork the shift register wire and send it to an output. Select the Use Default Value option for this output for this output terminal, so that the other cases (writing, initializing, etc.) just output an empty array of waveforms, which LV can do very efficiently.

[vgravel]

Thanks Hummer1 and Jarrod for the suggestions!

I will try Jarrod's way and see if it helps.

Vincent

[vgravel]

Jarrod solution seems to have improve performance significally.

So I guess the thing to learn from this is that when data are passed to an indicator, a copy is done even if the front panel is not in memory.

Thanks again!

Vincent