Cleaning up Local Variables

[DL84]

I inherited a program about a year ago, and since then have been adding new features to it.  Problem is when I took over the project it was very laggy.  The program is a large 24/7 always on program used for testing hardware.  I'm looking into ways to improve its performance dramatically, without redesigning the entire project.

The program uses on a magnitude of 200+ local variables sending data all over the place.  Needless to say its trainwreck of wasted memory locations.  I have considered having a massive shift register and carrying along the value of every local inside it as a cluster to get rid of all the buggers.  Then where ever a local was used previously, I could use an unbundle by name and call that value.  Would this be the best way to go about doing this you think?

Or any option on where else to start with improving the code?

[johnsold]

That approach will work. I have used it on a several projects. All the data is on a wire or a small number of wires and the Bundle/Unbundle by name nodes provide documentation.

You can use the Profile tools to show buffer allocations, memory use, and timing to identify parts of the program which may be bottlenecks.

Without seeing the program and knowing much more about its details, it is difficult to offer more than vague generalities.

Sometimes a redesign is a better way to improve a poorly written program. For example changing a program written with multiple sequence to a state machine architecture might be a huge improvement, but almost impossible to implement as a gradual modfication of the original. Do you have a good specification for what the original (or improved) program is required to do?

Lynn

[PaulG.]

Don't mean to be too discouraging, but "I have a bad feeling about this." You inherited poorly written code, and now you want to add features to it. It's a tough call but you may want to seriously consider just re-writing the entire application. My rational: I've been there. Looking back I probably spent twice as much time getting crappy code to work and THEN adding new features than I would have just starting from scratch. More so if the original code is poorly documented. Just my $0.02.

[mikeporter]

When approaching a project of this magnitude I have found it helpful to remember that this can be an iterative process. In other words, you don't have to fix everything at once. Correcting the data propagation and making sure the error clusters are connected up will be a good first step and will help you understand the code better. As you are going through the code you will find things that need fixing but don't have time to get into. Mark these locations by adding a free text comment in the code containing the word "broken" and a brief description of the issue. In this way you can find the locations quickly in the future. I have also found it helpful to color such comments with an orange background.

PaulG's comments are good, but its a judgment call. If you are confident that you know the process well enough you can give a try at the reimplementation up front. It's partially a judgment call, partially personal preference, partially business constraints.

Mike...

Message Edited by mikeporter on 07-12-2007 02:08 PM

[DL84]

There's one thing that concerns me though with sending all those variables along one line.  The program I took over is a test program.  I created a summary screen for two of those test programs running at once. 

How it works is, it has indicators for 4 locations.  Each location containing 7 indicators.  Thats 28 Variables that have to be checked + 12 Variables for some tower lights.  In order to get those current values I create a reference of the VIs that I took over, use property nodes to set up an array with all the controls from the reference listed.  Then I have a loop for each variable to be checked by referencing that control label listed.  See pictures below.

If I change how all the variables are managed...How would this change?

See pictures for how I'm getting those values...

[falkpl]

Another method fro getting rid of locals is to use an "Action engine" essentially a shift register and code to hold variables or groups of variables.  You can have a read and write mode of operation,  this is much like a static class with private data and a set and get function.  the buty of this approach is that you can move thoese locals to subvis without having to pass the values down with a wire.  As for my "two cents" I cant put then in because if it is a penny fro your thoughts but you put your two cents in someone is making a profit!

Paul

[johnsold]

The Value property node is the slowest way of updating a control or indicator, although it does have the advantage of being programmable which seems to be used in your pictures.

I can't see all the code, but I suspect that you do not need all those internal loops. If the control name strings were put into an array, one loop would probably be sufficient. Since all the controls are boolean there should be no need to convert to variants.

Lynn

[altenbach]

All these while loops (picture 2) are a big waste of resources. Especially since each iteration contains a property node. It seems each while loop rattles through all the labels until it find the correct one. All you need to do is extract an array of labels once before the main loop starts, then you can use "search array" on the array of labels followed by "index array" on the array of references to get the right reference.

Still, maybe there is a way to eliminate these references entirely. Depends on the code.

[DL84]

If I posted a copy of that vi with all the while loops, think it would help?

I agree there has to be a better way of doing it than is currently done.  Its not a very deep vi, pretty easy to understand all it does is update a bunch of variables to be displayed, and control fieldpoint tower lights.

[Ben]

I would be suprised if all the ref loops are major part of the poor performance.

Ben