Very slow subvi call (~10 seconds)

[CantankerousBullMoose]

I have a main VI in a large application which calls a subVI.  I'm finding that the main VI tends to hang up, and I've traced the problem back to this one subVI.  I was using probes to check timing.  What I found was that timestamp on a probe for the error cluster leading into the subvi and the timestamp for a probe on the error input inside the subVI were about 10 seconds apart.  So in the sample image below, probe 2 inside the subvi has a timestamp 10 seconds after probe 1 on the main vi.  The subvi is inside a case structure in the main vi, so it doesn't seem like there's opportunity for poor dataflow/race conditions.  I can't find other instances of the subvi that could be blocking this one, the run time for the subvi (aside from this overhead time) is under 100 ms, and enabling reentrancy on the subvi doesn't fix the problem. Further complicating matters, this used to work correctly (100 ms per call) and this problem developed overnight with no changes to the code.  I've played around a little with inlining and execution priority, but I would not generally expect that either of those could make a difference of 10 seconds for a single subvi call.  What's going on here?

[johnsold]

Ten seconds sounds like the default timeout on some DAQ and VISA VIs or functions. Is there anything like that inside the subVI?

Did highlight execution get turned on for that subVI?

Lynn

[altenbach]

Is the subVI set for exection highlighting? Is the panel of the subVI closed?  What kind of "stuff" happens there? Is anything iteracting with hardware, network, disk, etc.

[CantankerousBullMoose]

Highlight execution is off, and the problem happens whether the subvi front panel is open or closed.  As for the "stuff" it's all VISA calls to automate a piece of test equipment.  But the "stuff" seems to be running at normal speed; if I put a probe on the other side of the Error Case Structure in the subvi, it has the same timestamp as probe #2.  That was why I left it out, because it seems like something is happening before I even get to anything that should be executing inside the subvi.  The case structure in the main vi is just as simple as is shown here, although there's a little bit more going on to come up with the boolean wired to the selector.  The subvi is all by itself in the case structure, and I'm putting the probe inside the case structure, so it seems like there shouldn't be a lot of other stuff going on at that level to impact the timing, I think.

[Ben]

Provided you have not changed the default execution system...

Antivirus non-sense can play havoc on calling sub-VIs if for some reason it deems it will tie-up the processors. Watch you Task manager whil ehte delay is observed, showing all processes and see what porocess has the PCU when the delay occurs.

Ben

[thoult]

Does your LV license include the Desktop Execution Trace Toolkit? If so, you can get a better idea of the call chain timing around that subVI by using it.

If not, I've been no help.