Showing results for 
Search instead for 
Did you mean: 
Reply

Darren's Weekly Nugget 02/22/2010

Darren's Weekly Nugget 02/22/2010

[ Edited ]

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. Smiley Happy

Message Edited by Darren on 02-22-2010 11:07 AM
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman
Message 1 of 17 (4,374 Views)

Re: Darren's Weekly Nugget 02/22/2010

The obvious question is: what kind of performance hit?
0 Kudos
Message 2 of 17 (4,365 Views)
Reply
0 Kudos

Re: Darren's Weekly Nugget 02/22/2010

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.
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman
0 Kudos
Message 3 of 17 (4,342 Views)
Reply
0 Kudos

Re: Darren's Weekly Nugget 02/22/2010

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 (4,336 Views)
Reply
0 Kudos

Re: Darren's Weekly Nugget 02/22/2010

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 (4,309 Views)

Re: Darren's Weekly Nugget 02/22/2010

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 (4,259 Views)
Reply
0 Kudos

Re: Darren's Weekly Nugget 02/22/2010


Ray.R wrote:

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


 

 

Agreed.

Message 7 of 17 (4,254 Views)

Re: Darren's Weekly Nugget 02/22/2010

[ Edited ]

 


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
0 Kudos
Message 8 of 17 (4,200 Views)
Reply
0 Kudos
Highlighted

Re: Darren's Weekly Nugget 02/22/2010


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 (4,169 Views)
Reply
0 Kudos

Re: Darren's Weekly Nugget 02/22/2010

 


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.

0 Kudos
Message 10 of 17 (4,142 Views)
Reply
0 Kudos