09-11-2009 11:30 AM
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.
Stop using the locals and use a shift register to stor the data.
Ben
09-11-2009 11:34 AM
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
09-15-2009 11:06 AM - edited 09-15-2009 11:11 AM
@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.
09-15-2009 11:21 AM - edited 09-15-2009 11:28 AM
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.
09-15-2009 11:34 AM
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
09-15-2009 12:12 PM
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.
09-16-2009 07:49 AM
And to pad out what the others have said;
and
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