trivial question!

[lpaza]

Just a simple question really.  I was just wondering whether an application created in LabVIEW will put less strain on your CPU when it runs compared to the same vi run through LabVIEW.  I assume it is, but is the difference considerable?

Regards

Luke

[Ben]

Automatic Error handling and debugging are the only  things that are different CPU wise. So if you handle all of your error clusters and disable debugging, the CPU load should be about the same.

Ben

[jyang72211]

Are you talking about an exe made in labview vs. running the code through the labview application?

Yik

[lpaza]

Thanks for the responses.  Yik, I think you've got it, in more detail, I'm talking about the difference between running a vi you've made through LabVIEW compared to when you convert the same vi to an exe and install and run it on another PC for instance.  I hope that is a little clearer.

Ben, I vaguely remember noticing a large difference in mem usage between the two when I was poking around in task manager.  I don't suppose this would make a difference if you going for max performance.  I'm not quite a computer expert so I hope it makes sense!

Cheers

Luke

[Cory_K]

I guess you could take into account the memory that has to be loaded when you have the LabVIEW environment open,

but that has nothing to do with CPU. For all intents and purposes, I would say it requires the same CPU either way.

[altenbach · Accepted solution]

---

lpaza wrote:

I was just wondering whether an application created in LabVIEW will put less strain on your CPU when it runs compared to the same vi run through LabVIEW. 

---

Asking about "CPU strain" is probably too narrow. As Ben already mentioned, built applications have automatic error handling and debugging disabled. Debugging causes a certain overhead that is probably only noticeable when benchmarking some serious computations. A typical program should never be CPU limited for extended periods of time, so it should not matter. The differences are similar to running the program on slightly different (faster or slower) computers, so they are irrelevant in the grand scheme of things. Design your code to run well on minimal hardware and everyone will be happy. A computer typically runs dozens of other things in the background, so don't write a CPU hog. Play nice!

Code that strains the computer in the development system, will not run much better as an executable. Don't expect a tricycle to magically turn into a rocket ship. The executable will still be a tricycle, but the hill might me 1 degree less steep. 😄

Of course a built application is much leaner in general, e.g. in terms of memory footprint. It does not know how to edit diagrams, compile code, convert old VIs to the new version, etc. It will also load faster because all the diagrams and most front panels are removed and thus don't need to load.

The development system is necessarily much richer because it can do, and does, all these things. Of course it only uses CPU if something needs to be done, but it will take up more memory resources n general.

What are your concerns? Can you tell us what prompted the question? 

Message Edited by altenbach on 03-05-2010 09:23 AM

[lpaza]

To be honest it was mostly curiosity over concern.  My company have been using NI, but never Labview so they tested it on me (the intern guinipig) and I made a few programically messy but functional programs a few months ago.  As I'm becoming more familiar with it, i'm just neatening them up and was just wondering about differences in performance when they're moved to other PC's.  Thanks for all the responses though guys

[Mark_Yedinak]

As mentioned earlier the differences in performance will be insignificant for the execution of the code in eitehr environment. The big difference is that poorly written code will perform poorly and well written code will perform effeciently. Do a good job coding your application and your shouldn't have any performance issues.

[Cory_K]

---

Mark Yedinak wrote:
... The big difference is that poorly written code will perform poorly and well written code will perform effeciently....

---

Haha, well said! Couldnt get more simple than that

[Ben]

---

Mark Yedinak wrote:
... The big difference is that poorly written code will perform poorly and well written code will perform effeciently....

---

The problem with the simplicity of that statement is that an untrained eye could have trouble distinguishing between poor and well written LV code.

But then again, Christian's code always looks good. But I know he cheats. 

Ben