the memory of an array 2000*2000 is greater than 32Mb

[falkpl]

I bench marked my code in LV8.61.  I cant test it in 2009 to verify your results (my 2009 PC is busy right now), interesting that you are achieving a different result, what OS are you running.

[cbenard]

Windows XP pro

[smercurio_fc]

---

falkpl wrote:
 what OS are you running.

---

That's shown on the screenshot. 

I don't have time to look at this in detail this morning, but I thought I remembered reading at some point about some peculiarities with shift registers in 2009. In this post DFGray recommends using a single-element queue or a data value reference. For small arrays my opinion is that it's a bit cumbersome to use queues or data value reference. However, in this case, I would agree with DFGray that a single-element queue or a data value reference is the better approach. If you use a single-element queue, for example, the memory allocation is as "expected". 

[cbenard]

Hello,

Thank you for your help,

The single-element queue uses 32MB for the 2000*2000 doubles as the theoretical value, I don't understand the difference between this method and the array method.

I tried too the array method on the LabView 8.6 (vs labview 2009), and I had the same results i.e a RAM memory used superior to 32M.

The queue method should be a solution but the programming would be more complicated because I analyze data from files...

I'm interested in other solutions if you have some ideas, especially if s.o can explain the difference of memory in my method.

Christelle.

[Norbert_B]

Christelle,

can you please post the vi you used for your screenshots?

Norbert 

[cbenard]

Hello

In order to compare my results with the Falkpl's ones I've used his vi, so you can find the vi in page 1.

Christelle.

[jtagg]

Hey,

LabVIEW 8.6 and LabVIEW 2009 behave differently in this example and here are some of the results I was able to get using the VI on the first page from falkpl:

1. LabVIEW allocates 2 32MB buffers: one for the creation of the array in the case structure, and one at the shift register (use the "show buffer allocations" tool to see that). It seems that since we have a case structure, LabVIEW doesn't keep it all in one buffer.

2. LabVIEW 8.6 allocates a 32MB buffer when the VI is opened, before it is run. This can be noticed in the memory usage tab of the VI as well as the task manager.

3. Run the VI: the task manager allocates another 32MB, which are then freed after running the VI.

4. Close the VI: the other 32MB are freed.

5. Open it with LabVIEW 2009: no buffer is allocated.

6. Run the VI: two buffers are allocated

7. Stop the VI: both buffers are freed

Conclusion:

It seems that LabVIEW 2009 has improved it's algorithm as it now doesn't allocate anything until run-time since there is a case structure. LabVIEW 8.6 creates a buffer even though the True case may never actually be called. This causes some metrics differences to be noted when running the VI on different LabVIEW versions.

I hope this sheds some light on the matter.

Regards,

[falkpl]

Very interesting, looks like I will be looking much harder into the data reference in 2009 (finally made the official switch).

Is there an app note on large memeory allocation management for 2009 to show the advantages of the new features.  I have found the inplace memory management introduced a few years ago to change the way I handle data structures (arrays of clusters vs multiple arrays).  Also is there a utility for checking memory inefficiencies - I know show buffer allocations, but is there a tool to suggest at allocations a better architecture?

[jtagg]

Check out this thread, particularly the 3rd post by Damien Gray:

http://forums.ni.com/ni/board/message?board.id=170&message.id=429136#M429136

Like he says, it doesn't completely change the way you should manage large datasets, but does make it easier.

[smercurio_fc]

---

jtagg wrote:

Check out this thread, particularly the 3rd post by Damien Gray:

http://forums.ni.com/ni/board/message?board.id=170&message.id=429136#M429136

Like he says, it doesn't completely change the way you should manage large datasets, but does make it easier.

---

Joseph, your URL is messed up. Here's the corrected link: http://forums.ni.com/ni/board/message?board.id=170&message.id=429136#M429136