using display timing to detect bottlenecks

[EngrStudent]

I have a decently large VI comprised of layers of sub-VI's and some MathScript.

Sometimes, when I am working on it, it takes about 30 seconds to display the Front Panel.  I just see the little window-8 analog of the hourglass spinning.

If LabVIEW is taking that long to "think" there is a problem.  It isn't telling me what it is doing, only that what it is doing takes so much resources that it can only display blank white panes while it is doing so.

You might want to fix that.  I'm running an 8-core Xeon, there isn't any lack of computing resources.  It is a software bottleneck.

[X.]

You probably have too many sequence structures in your diagrams.

[RavensFan]

X,  Where does a comment about sequence structures fit into this?

EngrStudent.  What the heck are you talking about when you say "display timing"?  I have no clue what idea you are proposing here.

[X.]

A little humor after a long day... EngrStudent has been a big proponent of the Sequence Structure in his posts (or replacement thereof). But as I do not suffer from inexplicable blank FP when using LV (using sizable projects), like you, I would suggest to first run this issue by others in the regular LabVIEW forum and if verified as a reproducible issue, get it flagged as a CAR.

PS: I use a lot of sequence structures myself. As carpet to hide passthrough wires in state machines. So that's one possible source of the "problem" to eliminate.

[RavensFan]

X,

Okay.  I can understand that.  I hadn't remembered EngrStudent's other posts to see a connection there.

[EngrStudent]

I am militant about not having any frames that are more than one element in length.  I use them for order, but have been pinky-promised that using them in the way that I do doesn't impact performance.  I have used them in that way often enough to believe it.

There are likely 3 interacting factors.  I am moving large-ish heterogenous structures/clusters.  I am making them interact with mathscript (~1000 lines, built and tested in MatLab so older vocabulary) and the nesting of VI's is deeper than I like.  I also am passing ~250col by 2500 row 2d DBL tables around through this.

I was editing, not running, when the front pane locked up.  It happened solidly enough that I can reproduce it, I'm sure.

The problem is, it is internal/proprietary.  I don't know that I can share source code without an NDA.   I can talk privately on this subject.  

My to-do items: prove reproducibility, get more metadata, and then talk to legal about sharing it.

If I did a screen capture on say ~20 pixels that are not white and in "random" or at least not exclusively regular places in my application, then it could be (compressed sensing) fast.  I could test whether the front pane is showing.  If I could independently measure how long it takes to redraw, then I could get an idea of whether there was a bug.  The timing on measurement would have to execute separately from the frame, and might need integration with a system clock to tell how long it was since a change happened.  (I based this idea on how I suspect DocuColor hid itself from the EFF.)  You could then include a string that encodes a compressed time-series of response time/quality of the panes before the crash.  This might give a timeline for visual cues that is independent of the stack, and that gives information that your current crash report does not.

[X.]

Your "no performance hit" statement might not be strictly correct.

If you start from the test VI I used in another thread, and keep adding sequence structures (instead of disable structures), you may get results similar to the followong ones (obtained in a W7 virtual machine running on a MBP 2.3 GHz i7).

# empty sequence structure (SS) followed by average +/ standard deviation of iteration duration and then the difference with the previous result: 

0 SS: 127.5 +/- 6.1 ms

1 SS: 187.0 +/- 3.8 ms; 60 ms

2 SS: 247.5 +/- 2.6 ms; 60.5 ms

3 SS: 461.7 +/- 3.0 ms; 214.2 ms

I guess you get the idea. Since each iteration is executing the same loop 1E8 times, I conclude that adding an empty SS (or DS or probably any other object) takes at least 0.6 ns (in debug mode) but could be as high as 2 ns. Whether that matters for your application is up to you to judge.

[Darren]

Any idea that has not received any kudos within a year after posting will be automatically declined.