NXG - Array Size - Does anybody know how expensive this function is?

[flycast]

I find myself using this pattern a lot to be able to either get a count of data in a waveform or to be able to index the last element of an array:

 

Obviously an array of four elements is trivial. When I have an array of 100,000+ or 1,000,000+ doubles and I have to do this multiple times it may not be.

Two questions:

1. Does anybody know how expensive getting an array count is in terms of processor?
2. Is there a better way to index the last element in an array? I if so I haven't found it yet.

[Worle]

LabVIEW stores the size of the array at the beginning of the block of memory where the array is stored. It is a pretty safe bet that the array size primitive is just reading that bit of memory so it won't matter if your array only has one element or 10,000

https://www.ni.com/docs/en-US/bundle/labview/page/how-labview-stores-data-in-memory.html

This is how I achieve this functionality, I haven't seen another way of doing it.

Admittedly I haven't migrated to NXG yet so there may be something new.

[billko]

---

@flycast wrote:

I find myself using this pattern a lot to be able to either get a count of data in a waveform or to be able to index the last element of an array:

 

Obviously an array of four elements is trivial. When I have an array of 100,000+ or 1,000,000+ doubles and I have to do this multiple times it may not be.

Two questions:

1. Does anybody know how expensive getting an array count is in terms of processor?
2. Is there a better way to index the last element in an array? I if so I haven't found it yet.

---

I just reverse the array and index the first element.  It might be a tiny bit faster because no decrement function, but probably negligible even with big arrays.  As I understand it, there is no array manipulation; LabVIEW just reads the array backwards.

[flycast]

Great! How did you know this bit of knowledge - that is, how NI stores the data in the array?

[flycast]

---

@billko wrote:

---

I just reverse the array and index the first element.  It might be a tiny bit faster because no decrement function, but probably negligible even with big arrays.  As I understand it, there is no array manipulation; LabVIEW just reads the array backwards.

---

Makes sense. Speaking as a text programmer reversing the iteration loop start and end and incrementing by a +1 or -1 is much more efficient. I am learning the "NI" way though. I would assume that NI has taking great pain to make sure that handling the data is as fast as possible. It seems to be at the heart of the programming need.

I guess as you point out if the size of the array is stored in the array code then it really make almost no difference. Probably more important is choosing a way and being consistent throughout the project.

[paul_cardinale]

---

@billko wrote:

---

@flycast wrote:

I find myself using this pattern a lot to be able to either get a count of data in a waveform or to be able to index the last element of an array:

 

Obviously an array of four elements is trivial. When I have an array of 100,000+ or 1,000,000+ doubles and I have to do this multiple times it may not be.

Two questions:

1. Does anybody know how expensive getting an array count is in terms of processor?
2. Is there a better way to index the last element in an array? I if so I haven't found it yet.

---

I just reverse the array and index the first element.  It might be a tiny bit faster because no decrement function, but probably negligible even with big arrays.  As I understand it, there is no array manipulation; LabVIEW just reads the array backwards.

---

Hmmm.  Doesn't that mean that internally it has to do subtraction when indexing?  Is that going to be faster than decrementing the array size?

[paul_cardinale]

If I were inventing a programming language, I would have it interpret index -1 as the last element of an array, index -2 the 2nd to last element, etc.

In other words, arrays would be circular.

[mcduff]

---

@paul_cardinale wrote:

If I were inventing a programming language, I would have it interpret index -1 as the last element of an array, index -2 the 2nd to last element, etc.

In other words, arrays would be circular.

---

It is like that in Mathematica; maybe all LISP like languages?

mcduff

[altenbach]

---

@paul_cardinale wrote:

If I were inventing a programming language,

---

Maybe you remember this discussion. 

[altenbach]

---

@paul_cardinale wrote:
Hmmm.  Doesn't that mean that internally it has to do subtraction when indexing?  Is that going to be faster than decrementing the array size?

---

Either way it has to do some simple calculations on scalars, which are completely irrelevant for performance and independent of array size.

---

@flycast wrote:

I find myself using this pattern a lot to be able to either get a count of data in a waveform or to be able to index the last element of an array:

... 

Obviously an array of four elements is trivial. When I have an array of 100,000+ or 1,000,000+ doubles and I have to do this multiple times it may not be.

---

As has been said, LabVIEW is (and needs to be!) fully aware of the array size at all times and getting it is O(1), i.e. independent of data size and ultra-cheap. (Thus the "relative cost" is actually higher for small arrays ;))

If you have (or think you have) performance problems, this is not the place to look. Often changing algorithm, execution order, or optimizing for better in-placeness can give you orders or magnitude improvements while fidgeting with small integers will never yield anything measurable. Since you seem in constant need (your words!) to get the data size, it implies that your array sizes are changing which can be orders of magnitude more expensive for the memory manager since arrays need to be stored in contiguous memory. Often things can be rearchitected using fixed sizes where you can keep the index of the current last valid element in a shift register.

Feel free to show a slightly larger and more realistic piece of code, so we can potentially offer suggestions.