Is there any drawback of using "Subvi" or "Local variable"?

[Camu]

Hi, i want simplify a very complex Vi by using subvis and local variables. Is there any drawback of using too many subvis?

Any help is highly appreciated.

Thanks in advance!

[BillMe]

I guess you can make sub-vi's TOO simple hence ending up with TOO many, but if you know your VI is overly-complex then you need to re-design and modularize (sub-VIs). Also, I would discourage overuse of local variables. NO local variables is ideal.

[andre.buurman@carya]

Do you have any experience in other languages.

SubVI's are like functions or procedures or can even be entire modules.

Read a local variable is nothing more than using the variable name again in a text based language.

In my opinion the performance issues with Locals only apply when working with large datasets and slow machines.

Regards,

André

[mikeporter]

First in terms of Local Variables: the best advice is to start by counting up the number of them you use. If the total is greater than zero, you have too many. I have heard lots of arguments about performance issues and memory consumption - but to my mind these are all side matters. The basic issue is that they are unnecessary in well-written code. The fact that they exist at all is indicative of a design or implementation problem in your application. They are also an open door to race conditions because access to them is uncontrolled.

Second, on the topic of subVIs there is no such things as too many subVIs as long as the application is well-structured. A good program should exhibit a hierarchical structure where VIs are constructed out of other lower-level VIs. A good VI is one that (within its hierarchical context) has a very simple function. For example, a good interface level instrument will allow you to do one thing: send commands to a particular type of instrument and return the results. It implements the protocol that the given instrument requires for communications. It doesn't care what command is being sent - that is the job of higher-level VIs that use it as a subVI to communicate with the instrument. But note that these command-level VIs also have simple definitions: things like Set Trigger Level or Read Input Voltage. Next, these VIs are themselves used to synthesize even higher-level functionality like: Turn on stimulus or Monitor Device Output. And so it goes, each layer building on the ones below it until you get to one that has a very simple definition: Run Test. Then you're done - or at least you're done until someone decides that they want to use your test system as an instrument is a larger system or manufacturing process.

Mike...

Message Edited by mikeporter on 08-25-2007 10:59 AM

[altenbach]

Excellent answer Mike!

---

Camu wrote:

Hi, i want simplify a very complex Vi by using subvis and local variables. Is there any drawback of using too many subvis?

---

Well, this is backwards. Once the program is finished and working well, it is probably almost too late for efficient code refactoring. These ideas should be implemented at the beginning of coding.

local variables

You must have some specific ideas why you think that local variables can be a tool to simplify existing code. What do you have in mind? Do you want to replace a complicated long wire with local variable stubs on both ends? Not only does this complicate the code, it will introduce unchecked race conditions and most likely require the need of yet another superfluous, possibly hidden front panel opject. None of this will simplify the VI! Usually, you want to eliminate local variable to simplify code. 🙂

subVIs

You need to look at your code and decide if there are duplicate operations at various locations of the VI that cannot be e.g. reduced to a single instance by using a loop, for example. If your idea of "simplification" is just to select random areas of the diagram followed by "create subVI", you are only curing the symptoms of a messy, overloaded diagram by creating many "single-use", messy subVIs. This is like sweeping all the dirt under a rug. The mess is still there, but buried under an additional layer. SubVIs need to be functional  and reusable and with a clear and useful purpose. Again, this is something that should be decided before starting to write the main program.

As you can see, we are somewhat puzzled about your ideas of "simplification". Can you be a bit more specific on what you have in mind and why you think it will simplify things?

[altenbach]

... and to answer the question in the title: Is there any drawback of using "Subvi" or "Local variable"?

Local variable do impose a performace penalty because they require an extra data copy. This can be significant if you are dealing with large data structures. The main draback are race conditions as already mentioned.

Compared to "inlined" code, subVIs also impose a calling overhead so it is important to design them correctly. For example of you have an inner loop containing only a subVI call, it might be better to make the loop part of the subVI, for example. Most of the time the higher code abstraction of subVIs is worth much more than the penalty.

[altenbach]

---

andre.buurman@carya wrote:
Read a local variable is nothing more than using the variable name again in a text based language.

---

NO! It is very different! You cannot compare sequential, text based code with dataflow code. This is a very dangerous comparison because LabVIEW does not execute code in a predictable order if you have disconnected code islands, each using locals. In order to cure the race conditions, you would need place all code segments into frames of a sequence structure, further complicating the program.

For some easy reading, have a look at this old thread: http://forums.ni.com/ni/board/message?board.id=170&message.id=112401#M112401

As has been mentioned during several Keynotes at NI week, LabVIEW has excellent capabilities to automatically use multiple processor cores due to its inherent parallelism. Currently, the main push in processor development is going to multicore designs and LabVIEW code will really shine while most text based code will be stuck in the mud. Of course if you chop up your code and sequentialize (sic ;)) it with sequences and local variables, you're back to square one and are throwing away one of the most powerful advantages of LabVIEW. 🙂

I am so glad that LabVIEW does not contain a vertical flat sequence, or we would see something that even more resembles text code. 😄

---

andre.buurman@carya wrote:
In my opinion the performance issues with Locals only apply when working with large datasets and slow machines.

---

"Slow machines" is a meaningless term. I remember when the '486 processors first came out, it was argued that they are so much more powerful than the '386 that they should be used mostly for server applications. A poorly written program can bring any processor to its knees. A well written program should run well on any hardware. It is virtually never a solution to "cure" a sluggish program by throwing faster hardware at it. Same with memory. Sure, you can go to 4GB, but that will give you only a factor of two or three over the typical RAM (and you cannot even use it all on 32bit architectures), almost insignificant! Alternatively, you can often streamlime the code and easily eliminate as many extra data copies.

Compared to the hardware that will be available in a few years, even the fastest machine today is extremely slow. Years ago, fantastic applications have been written that run well in a 100MHz P1 with 64MB of RAM.

In summary, if you want to fully harness the power of current and upcoming multicore CPUs, you better quickly loose your sequential thinking and write LabVIEW code the way it was intended, using the power of dataflow to your advantage. Good luck! 🙂

[Gabi1]

Altenbach you should be sent out as spokeperson for Labview loby!
i love the clarity of your arguments.

on a side note, i am not totally accepting the idea of "zero" locals. i found them necessary in some cases, especially for booleans with specific latching mechanisms. they could be exchange with "value" property node, but it comes out to the same.

[altenbach]

---

@Gabi1 wrote:
on a side note, i am not totally accepting the idea of "zero" locals.

---

Oh, yes! I use local all the time. This is not some religious thing. Locals definitely have their place, especially in dealing with UI issues. However, they should not be used as a cheap substitute for naked "variables" as discussed here.

I don't think there is a LabVIEW lobby, and I'm certainly not part of it. I don't even own NI stock. 😮

LabVIEW works they way I think and has empowered me to do things with ease that I was struggling forever with text based code in the past. So, yes, I am a fan, groupie, (or whatever you want to call it) of the visionary ideas layed out by Jeff Kodosky and crew over 20 years ago. LabVIEW is something I can use everyday and it makes my life easier. That should count for something! 🙂

[Gabi1]

Ho Yes! count me in as big fan!
i rather do labview and use NI tools for developments of control systems all day long than any other job
thing is, i am a post doc right now, so have too many other things to do ( like ultracold molecules out of atomic Bose Einstein condensates...)

i also found out LV to be quite efficient: this is not an objective observation, but i made some MC and molecular dynamics simultations in LV, which turned out to be faster than their counterparts in Fortran!

Amazing compiler this thing...