Waveform Buffer Allocations

[bbean]

Why does indexing an array of waveforms create a buffer allocation, but indexing a 2d array does not?

[Aristos Queue]

The one that has a buffer allocation is an element of the array.

The one that does not have a buffer allocation is a subarray.

A subarray is a reference back to the original array and does not require any data copying. An element is an independent item and gets copied out of the array. If the output of the first Index Array was an array data type, we could have a subarray of a single element, but it isn't an array output -- it is an element.

[bbean]

QUOTE(Aristos Queue @ Dec 12 2007, 12:51 PM)

An element is an independent item and gets copied out of the array. If the output of the first Index Array was an array data type, we could have a subarray of a single element, but it isn't an array output -- it is an element.

Thanks for the description.

Whats the point of using the waveform datatype (when you have multiple channels) then? If everytime you need to look at the data for an individual channel, a copy of the data is made (even if you are not altering the data). The LabVIEW compiler isn't smart enough to deal with this issue? :thumbdown:

Does anyone have tricks for using waveform arrays or should I go and convert all my DAQ code to 2D arrays?

[Aristos Queue]

QUOTE(bbean @ Dec 12 2007, 02:55 PM)

Does anyone have tricks for using waveform arrays or should I go and convert all y DAQ code to 2D arrays?

In LV8.5, use the Inplace Element Structure with the Index Element option.

[Kevin P]

Aristos:

Simple question but I'm offsite and will likely forget to check this out for myself later. If my memory serves me, it appears that the 1D subarray taken from the 2D array is a ROW, whose elements would be stored in consecutive memory locations. Would there be a buffer allocation and data copy when extracting a 1D COLUMN from the 2D array, since those elements would NOT be in consecutive memory locations? In AI data acq, I'm much more likely to extract column-wise than row-wise since each column represents multiple samples from an individual channel.

bbean:

I'm interested in memory / performance tradeoffs of waveforms vs. arrays as well. I learned NI data acq before the waveform datatype was invented. When it came out, it looked to me like an overture to new users who might have trouble handling the relationship between sample rate and elapsed time. As with many other "innovations" that seemed to be aimed at new users, I've treated the critters with an abiding suspicion.

I almost always read my data acq channels as arrays. No biggie b/c I learned that way. I also tend to do a fair amount of somewhat-oddball counter stuff that makes the waveform unsuitable anyway. But over the years, more and more of the analysis and signal processing vi's seem to demand waveform inputs. I feel a bit like I'm being squeezed in a "resistance is futile" kind of way.

So to echo the question, what's the real dirt on waveforms anyway? What are the considerations for when they can cause a performance hit? If I have a data array whose wire terminates where I bundle it into a waveform, will the waveform simply take ownership of the array pointer? What kinds of things can be done in-place more readily with an array than with a waveform?

Finally, a side-rant:

One thing that contributes to my suspicion of NI's commitment to good, efficient code is that many of the shipped examples and vi.lib files, even many of the toolkits, have some pretty ugly block diagrams. I know that ugly doesn't *necessarily* equate to inefficient, but it demonstrates a lack of attention to detail which raises more doubts.

-Kevin P.

[Aristos Queue]

QUOTE(Kevin P @ Dec 21 2007, 09:49 AM)

Aristos:Simple question but I'm offsite and will likely forget to check this out for myself later. If my memory serves me, it appears that the 1D subarray taken from the 2D array is a ROW, whose elements would be stored in consecutive memory locations. Would there be a buffer allocation and data copy when extracting a 1D COLUMN from the 2D array, since those elements would NOT be in consecutive memory locations? In AI data acq, I'm much more likely to extract column-wise than row-wise since each column represents multiple samples from an individual channel.

Accessing a column of a 2D array would still be inplace. The subarray stores a start position, an end position and a stride. In a row, the start would be beginning of row, end of row and stride =1. In a column, it would be start of column, end of column and stride = lenght of row.QUOTE(Kevin P @ Dec 21 2007, 09:49 AM)

Finally, a side-rant:One thing that contributes to my suspicion of NI's commitment to good, efficient code is that many of the shipped examples and vi.lib files, even many of the toolkits, have some pretty ugly block diagrams. I know that ugly doesn't *necessarily* equate to inefficient, but it demonstrates a lack of attention to detail which raises more doubts.

As one of the C++ programmers, I might suggest that the C++ code is good enough that our G programmers generally don't have to worry about it. The quality of G code doesn't correlate at all to how well the compiler of the G code works. In actuality, I know the G programmers do pay a lot of attention to code quality and by and large the shipping code is very clean. Yes, you can find specific problem VIs here and there, but I don't give a lot of creedence to the position that there's "a lot" of ugly G that ships with LV. I don't know about the toolkits, as I've rarely delved into them, but the same programmers write most of those, so I'd be surprised if many ugly VIs exist there.

[Gary Rubin]

QUOTE(Kevin P @ Dec 21 2007, 10:49 AM)

I'm interested in memory / performance tradeoffs of waveforms vs. arrays as well. I learned NI data acq before the waveform datatype was invented. When it came out, it looked to me like an overture to new users who might have trouble handling the relationship between sample rate and elapsed time. As with many other "innovations" that seemed to be aimed at new users, I've treated the critters with an abiding suspicion.

I agree 100%. I never really adopted waveforms because, when they came out, I thought of everything other than the data array as "overhead" that I didn't really need or want.

Gary

[Neville D]

QUOTE(Aristos Queue @ Dec 21 2007, 09:50 AM)

...Yes, you can find specific problem VIs here and there, but I don't give a lot of creedence to the position that there's "a lot" of ugly G that ships with LV. I don't know about the toolkits, as I've rarely delved into them, but the same programmers write most of those, so I'd be surprised if many ugly VIs exist there.

Try looking at Vision examples. Most of them still use stacked sequence structures.

But other than that, the examples are reasonably well-written.

Neville (just back from vacation)

[crelf]

QUOTE(Neville D @ Jan 17 2008, 06:05 PM)

Try looking at Vision examples. Most of them still use stacked sequence structures. But other than that, the examples are reasonably well-written.

:thumbup: I agree.