How efficient is Graphical Labview

[richjoh]

After I compile my code to build an executable, how efficient is Labview compared to some text language, C, C++, C#, Java. Does it run just as efficient as CVI code?

I'm not new to Labview but I'm looking for paths to illustrate the efficiency compared to text language especially C#. I want to address myths that people are running scared with and spreading news that have no facts to back it up.

[nathand]

LabVIEW will rarely be as fast as compiled C, but it will also be less likely to crash since LabVIEW handles memory management, array bounds checking, etc for you automatically. Will the difference in speed be noticeable to your users? Probably not, unless you're continuously pushing a lot of data through computationally intense computations. There are people on this forum who need every bit of speed that LabVIEW can provide, and they occasionally write a C DLL when a specific portion of code needs to go even faster, but they're still using LabVIEW for the majority of their work.

The fact that LabVIEW is a graphical programming language is irrelevant once it's compiled. Compiled LabVIEW is machine code, just like compiled C or C++ (Java and C#, however, usually compile to bytecode that runs on a virtual processor, with a small performance penalty).

[altenbach]

Have you done a forum search, this comes up once in a while.

You can write inefficient code in any programming language, so it comes down to the skills of the programmer. You also should define what you mean by "efficient".

In terms of the time needed to write a fully functional feature rich program, LabVIEW wins hands down so here it is an order of magnitude more efficient. :D.

Or are you talking about execution speed for a given task, memory usage?

In terms of power usage, modern processors are orders of magnitude more efficient than older designs, so go with a 14nm Intel system if that matters to you. 

A well written LabVIEW program can be equally efficient if programmed correctly. Graphical programs are inherently parallel in nature so of your design can benefit from parallelization, LabVIEW will make it easier.

What kind of applications do you have in mind?

If you need time-critical real-time processing, you might want to go to LabVIEW RT and FPGA,  offloading the heavy lifting to dedicated hardware. This is easy using LabVIEW but much more difficult using traditional text programming.

Modern programs are rarely CPU and memory limited. My programs run equally well on a simple atom processor unless there is heavy processing involved.

[altenbach]

---

@richjoh wrote:

After I compile my code to build an executable, ...

---

LabVIEW is always compiled, even if run in the development environment.

You get a (often very small) improvement in performance because building into an executable typically elminates debugging code and unneded panels. You can get similar improvements by disabling debugging and ensuring that the front panels of subVIs remain closed.

Also have a look at my NI-Week 2015 presentation. 

[richjoh]

Altenbach, I agree with everything you mentioned above. What I mean by efficient is when a "large" program runs and does what it's written to do. Execution speed using compiled machine C# vs machine compiled code Labview, what the difference in execution time? In your opinion, is it unnoticable without a large large data set or number crunching? 

Nathand, you mentioned "LabVIEW will rarely be as fast as compiled C", why  is that considering memory manage and array bounds etc are  handle accordingly? Today's compilers have gotten more and more efficient.

I most often come across Labview code where the UI thread is bogged down by poor programming practice (over using the sequence structure) and this is the same with text based language that use functions that wait on the UI. 

[nathand]

---

@richjoh wrote:

Nathand, you mentioned "LabVIEW will rarely be as fast as compiled C", why  is that considering memory manage and array bounds etc are  handle accordingly? Today's compilers have gotten more and more efficient.

Whether compilers have gotten better is irrelevant. Bounds checking an array is an extra operation that LabVIEW code does and C code doesn't, so that's necessarily some miniscule amount of performance difference. On the other hand, accidentally entering an invalid array index won't cause your LabVIEW code to write data to an unintended location, the way it could in C.

[Bob_Schor]

If you are doing "pure number crunching", you might do better with a text-based compiled language, particularly if it had libraries of optimized numerical code.  If you are dealing with Human/Device interaction (including interacting with a Front Panel to allow Users to make choices, view results, etc., and especially displaying results in "real time" from instruments providing data or controls), then LabVIEW would definitely be my language of choice.

I've found that for "modest" number-crunching jobs, LabVIEW is quite fast and efficient, and the ability to develop, debug, document, and organize LabVIEW code is so much superior to text-based languages that I've used.

Bob Schor

[altenbach]

---

@Bob_Schor wrote:

If you are doing "pure number crunching", you might do better with a text-based compiled language, particularly if it had libraries of optimized numerical code.

---

LabVIEW has libraries of optimized numerical code too. 😄

[Bob_Schor]

The key word in my post was might (which does not necessarily make "right").  I've never had any complaints about LabVIEW's speed, particularly when factoring in "speed of development and ease of testing" ...

Bob Schor

[nathand]

---

@Bob_Schor wrote:

I've never had any complaints about LabVIEW's speed, particularly when factoring in "speed of development and ease of testing" ...

---

Reminds me of the following conversation, for which I sadly can't provide an attribution:

> I haven't seen a compiler beat a good assembler programmer yet.

You must only have looked at very small programs.  The compiler wins
on big ones because the assembler programmer dies before
he has finished writing the program.