LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Writing Data in a huge Data Array slows program down


johanneshoer wrote:

Darin.K wrote:

Locals, stacked sequences, and memory thrashing.  I anticipate some fun comments here. 

 

My advice is to do a search of the forums on Memory Thrashing, and among other things initialize a large array and replace elements instead of constantly appending. 


 

Darin,

 

thank you for the help. I tried initialising the array and then replacing elements instead of appending but it made it worse! 

 

I think I am on the wrong track.

 


That is expected when you are using locals.

 

If you use "Tools >>>> Advanced >>> show buffer allocations you will see a new buffer being used for your local.

 

Show_Buffer.JPG 

 

Stop using the locals and use a shift register to stor the data.

 

Ben

 

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 11 of 17
(1,314 Views)

Ok you have seen the beauty of the shift register.

 

Now go back to that performance tag link and look for "defer Front Panel updates". That property lets you control when LV redraws the screen.

 

warning!

 

Don't expect miracles out fo screen updates. if you try to refresh the sreen to often you will run into another set of bottle-necks.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 12 of 17
(1,313 Views)

@Ben,:

Thank you very much for your help. I have studied the performance tag a little and I fixed my program by using shift registers at some places, but not for every variable.

 

My program is for controlling a test bench and in the program there are about one hundret variables, which I need a different locations, so I used local variables a lot and I always considered possible race conditions.

Even though shift registers are nice, I can not place a hundret shift registers or local sequences in my sequence.

 

Darin mentioned stacked sequences. Stacked sequences are not good?

I placed a stacked sequence with lots of frames in a loop, because the control of my test bench is sequencial as well: scaning inputs, calculating something, displaying results, saving data, applying outputs, scaning inputs again, and so on. So where's the problem?

If my programming is problematic, please tell me. I am not aware, if I program badly.

 

Maybe I should change my style of programming? For example, I know C and C++, but every time I program, I program like in C, because thats the way I am thinking: sequencial, not object oriented.

Message Edited by johanneshoer on 09-15-2009 11:11 AM
Greetings Johannes
Using LabVIEW 7.1 and 2009 recently
0 Kudos
Message 13 of 17
(1,282 Views)

If I were you I would seriously consider changing your stacked sequences to state machines. Stack sequences by nature are difficult to maintain as well as pass data between frames. State machines (using a case statement within a while loop) will allow you to change or modify your code much more easily when the need arises. There are many variations of state machines such as the queued state machine or JKI's state machine model. LabVIEW is a data flow language. Sequence frames take the power of data flow away and turn LabVIEW into a sequential language.

 

As for the hundreds of variables I would first analyze your design and see if they truly are required. If you make your code more modular and use more subVIs you may find the need for many of these variables disappears. If they are still required you can investigate other options of passing your data between sections of your code. You could use functional globals, LVOOP objects or queues to name a few alternatives.

 

Another thing you may want to look at is separating your processing from your UI. Check out something like the producer-consumer architecture. This gives you better control over your UI and allows you to maximize the performance in your data processing and control the updates to the UI more efficiently. You don't really need to update the UI every time you read a value. If you place control of the UI in an event structure you can use user defined events to process display updates. In the mean time a separate parallel process will be handling all of your data processing tasks.

Message Edited by Mark Yedinak on 09-15-2009 11:28 AM


Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 14 of 17
(1,278 Views)

In addition to Mark's good advice I would add two things.

 

1.  LabVIEW uses a dataflow paradigm.  This is different from text based languages where execution of the code is sequential, one line after another.  In LV any node which has data present at all its inputs can run at the next time slot.  To become a good LV programmer, you need to understand and take advantage of dataflow.

 

2.  Put all the data you need to pass around to various parts of your program into one large cluster.  Wire the cluster through a shift register.  Use Bundle by Name and Unbundle by Name to gain access to the data.  One shift register = one wire for all your data.  The by Name nodes document which data elements are being used at any particular place in the program.

 

It is possible to design and code large, complex programs which are easily maintained and modified without using sequence structures or local variables.  Both have their uses, but only rarely are they the first or best choice.

 

Lynn 

0 Kudos
Message 15 of 17
(1,270 Views)

One minor variation regarding John's above advice would be to use typedefed clusters for your data. And rather than using one large, single cluster I would organize and bundle your data logically. That is, put the variables that are truly related to each other into a cluster rather than simply lumping everything together. Typedefs will help you when you need to update or modify the cluster definitions.

 

If you haven't already considered it you may want to check into taking some of the LabVIEW courses that are available. Even if you went through the online tutorials. Data flow programming is a different programming paradigm and it is best to have a good understanding of it to take full advantage of its power.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 16 of 17
(1,265 Views)

And to pad out what the others have said;

 

Nugget on Type definitions

 

and

 

Nugget on action engines

 

Both of those nuggets talk about how to organize store access and manuipulate your data. The rest of teh transition to the data flow paradigm, is to stop minding the computer's buisness, and just think about what data needs touched when.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 17 of 17
(1,226 Views)