Darren's Weekly Nugget 02/22/2010

[Darren]

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

[smercurio_fc]

The obvious question is: what kind of performance hit?

[Darren]

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.

[TCPlomp]

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

Ton

[Ray.R]

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

[tst]

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.

[LabBEAN]

---

Ray.R wrote:

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

---

Agreed.

[LabBEAN]

---

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:

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

[tst]

---

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?

[LabBEAN]

---

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.