LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Darren's Weekly Nugget 02/22/2010

I recently learned a new performance tidbit from one of our LabVIEW architects related to the automatic error handling setting on VIs:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

It turns out that, even if you have this setting disabled, the automatic error handling hooks for any unwired error output terminals on your diagram are not removed from the compiled code.  This is because there could be situations (one example is the Desktop Execution Trace Toolkit) where these hooks would be needed for debugging.

 

So to avoid taking a performance hit for any unwired error output terminals you can either (1) ensure the error cluster output terminals for all nodes on your diagram are wired (there is a VI Analyzer Toolkit test called "Error Cluster Wired" that can check for this), or (2) disable debugging on your VI (in other words, deselect the "Allow debugging" checkbox in the dialog shown above).

 

I figured that if a guy who helped write LabVIEW 1.0 felt this was worth mentioning, I should pass it on. 🙂

Message Edited by Darren on 02-22-2010 11:07 AM
Message 1 of 17
(8,504 Views)
The obvious question is: what kind of performance hit?
0 Kudos
Message 2 of 17
(8,495 Views)
I just did a very simple modification to one of my benchmarking VIs to try this out.  My cursory estimation is that the performance of a diagram that used the Format Into String function (it has an error output terminal) increased by about 2% when I wired its error output vs. when I did not.  Again, this is not an official number, just what I observed in this one benchmark VI.
0 Kudos
Message 3 of 17
(8,472 Views)

2 percent per unwired error terminal is quite a bit...

 

Ton

Free Code Capture Tool! Version 2.1.3 with comments, web-upload, back-save and snippets!
Nederlandse LabVIEW user groep www.lvug.nl
My LabVIEW Ideas

LabVIEW, programming like it should be!
0 Kudos
Message 4 of 17
(8,466 Views)

As a rule of thumb, I wire all error clusters, and they get wired to an error out indicator.  Not only is it good to maintain dataflow, it avoids (or reduced) the chances of having a popup message because of an unhandled error.

 

It does not surprise me that there is a performance tied to this because something has to monitor the unwired errors.

 

Thanks for the info on the performance cost.  It will give me additional reasons to support wiring all errors.

 

R

Message 5 of 17
(8,439 Views)

It's important to note that in an executable (where the AEH is disabled regardless of what you do), the diagram is removed by default, so presumably this hit won't exist there.

 

In such cases, I might care less about performance in the IDE. Of course, I ususally wire most error terminals (there are rare cases where I choose not to), so this isn't much of an issue.


___________________
Try to take over the world!
0 Kudos
Message 6 of 17
(8,389 Views)

Ray.R wrote:

It will give me additional reasons to support wiring all errors.


 

 

Agreed.


Certified LabVIEW Architect
TestScript: Free Python/LabVIEW Connector

One global to rule them all,
One double-click to find them,
One interface to bring them all
and in the panel bind them.
Message 7 of 17
(8,384 Views)

 


tst wrote:

 

It's important to note that in an executable (where the AEH is disabled regardless of what you do), the diagram is removed by default, so presumably this hit won't exist there.


 

tst appears to be correct.  In the attached sandbox project, the EXE runs without dialogs regardless of how I set Automatic Error Handling in the build specification properties.  If AEH is always disabled in executables, then what does the last option here do:

 

Build Spec VI Properties AEH.PNG

 

 

Looks like I may need to recant.

 

Darren-

Can you explain what the AEH build setting is used for?

Message Edited by LabBEAN on 02-22-2010 03:05 PM

Certified LabVIEW Architect
TestScript: Free Python/LabVIEW Connector

One global to rule them all,
One double-click to find them,
One interface to bring them all
and in the panel bind them.
0 Kudos
Message 8 of 17
(8,330 Views)

LabBEAN wrote:

 

If AEH is always disabled in executables, then what does the last option here do:


Maybe it works if you don't remove the diagram?


___________________
Try to take over the world!
0 Kudos
Message 9 of 17
(8,299 Views)

 


tst wrote:

 

Maybe it works if you don't remove the diagram?


 

 

I enabled debugging before building the EXE, connected through "remote debugging", and even showed the diagram before running the EXE (to make sure it was actually there) but still didn't see the dialog.


Certified LabVIEW Architect
TestScript: Free Python/LabVIEW Connector

One global to rule them all,
One double-click to find them,
One interface to bring them all
and in the panel bind them.
0 Kudos
Message 10 of 17
(8,272 Views)