VI Profiler on dynamic called VI archiecture

[James_W]

I have a question about debugging to put to the Gurus out there.

My architechure is this, Event driven Producer, which queues Data into the Primary Consumer Loop. Primary consumer Loop performs an action and Queues information into the Secondary consumer Loop which updates the front panel GUI.

The Primary consumer calls test VIs dynamically using a call by Ref node function.

I have a very simple test VI which I am repeatedly calling which is outputing the time since the whole test sequence started (in ms) to the Front panel.

For debugging I have put a conditional disable around the dynamic call function, and I can change it to call the test VI directly.

VI profiler is telling me that the execution of my run a test VI which does the dynamic call takes 0ms. This can't be true.

The results from VI profiler would indicate that I could run 20 tests in about 1 second, but it's taking me about 10 seconds.

I do 10 display updates (via property nodes to change the active row, colours and contents of a multicolum listbox) per test.

Any ideas how I should be debugging where the time is being lost? - VI profiler is not helping enough.

Cheers

James

[James_W]

To continue further with the debug.

I ran 20 test to benchmark my architechture to try to find out where the errors are.

config A (not waiting for GUI to update before starting next test, test is hardcoded

Can't insert table have attached file with results instead. Apparently this post is >10,000 chars.

As you can see there is a significant perfomance hit from updating the front panel during the running of the test. I expect some sort of performance hit, but not a hit of nearly 6 seconds over 20 tests just for display updates - especially when I can't see anything in VI Profiler. and a hit of 11 seconds to dynamically call a 17kB test VI 20 times???

What have I got wrong here? what debugging tricks can I use to isolate the delays?

I have attached a screenshot of the profiler sorted by average time taken after 1 run of the second column style test. As can bee seen, the VIs which update the Front panel take an average of 15ms to run. Ahh I've just answered part of my own question here 20*0.15=3secs

1)What is the most efficient way of updating the cells of a multicolumn list box at runtime (text, colours etc), do I have to use a property node or is there a faster way if I can get a wire to the subVI?

2) How can I make dynamic calling faster? Will loading all of the VIs before I call them cause the code to run faster if I am calling them by path?

[Ben]

---

James W wrote:

To continue further with the debug.

I ran 20 test to benchmark my architechture to try to find out where the errors are.

config A (not waiting for GUI to update before starting next test, test is hardcoded

Can't insert table have attached file with results instead. Apparently this post is >10,000 chars.

As you can see there is a significant perfomance hit from updating the front panel during the running of the test. I expect some sort of performance hit, but not a hit of nearly 6 seconds over 20 tests just for display updates - especially when I can't see anything in VI Profiler. and a hit of 11 seconds to dynamically call a 17kB test VI 20 times???

What have I got wrong here? what debugging tricks can I use to isolate the delays?

I have attached a screenshot of the profiler sorted by average time taken after 1 run of the second column style test. As can bee seen, the VIs which update the Front panel take an average of 15ms to run. Ahh I've just answered part of my own question here 20*0.15=3secs

1)What is the most efficient way of updating the cells of a multicolumn list box at runtime (text, colours etc), do I have to use a property node or is there a faster way if I can get a wire to the subVI?

2) How can I make dynamic calling faster? Will loading all of the VIs before I call them cause the code to run faster if I am calling them by path?

---

Use the VI itself to time hwo long it takes by getting the time before and after.

Opening a dynamic VI takes time. Load ahead of time use it and when done close it.

1) Def FP updates (to shut of  screen updates), hide the MCLB, update it, un-hide, un-defer. passing data directly to the MCLB via terminal is fastest but can't do color stuff without property nodes.

2) Pre-load

Ben

[James_W]

---

Ben wrote: Use the VI itself to time how long it takes by getting the time before and after.

Opening a dynamic VI takes time. Load ahead of time use it and when done close it.

1) Def FP updates (to shut of  screen updates), hide the MCLB, update it, un-hide, un-defer. passing data directly to the MCLB via terminal is fastest but can't do color stuff without property nodes.

2) Pre-load

Ben

---

1) 

And here comes the killer...

If I defer FP updates, the code runs slower!!! not faster.

If I change the MCLB from Synchronous to Asynchronous using the drop down menu before I run it has no effect on the run time.

If I change the MCLB from Synchronous to Asynchronous at runtime using at property node (not meant to do this), I get error 1073 and the GUI stops updating (sometimes while redrawing the screen half way down), but wiping over the FP window 10 seconds later shows the code has run significantly faster.

2) How do you preload 120 different tests all with the same VI pattern (generated from the same template) and ensure you have the correct VIs in memory without running them? (and producing loads of errors - these tests all logs any errors they produce to files)

I asked for the Guru's I didn't think I was going to the the Knights so fast!! Thanks Ben

[Ben]

---

James W wrote:

---

Ben wrote: Use the VI itself to time how long it takes by getting the time before and after.

Opening a dynamic VI takes time. Load ahead of time use it and when done close it.

1) Def FP updates (to shut of  screen updates), hide the MCLB, update it, un-hide, un-defer. passing data directly to the MCLB via terminal is fastest but can't do color stuff without property nodes.

2) Pre-load

Ben

---

1) 

And here comes the killer...

If I defer FP updates, the code runs slower!!! not faster.

If I change the MCLB from Synchronous to Asynchronous using the drop down menu before I run it has no effect on the run time.

If I change the MCLB from Synchronous to Asynchronous at runtime using at property node (not meant to do this), I get error 1073 and the GUI stops updating (sometimes while redrawing the screen half way down), but wiping over the FP window 10 seconds later shows the code has run significantly faster.

2) How do you preload 120 different tests all with the same VI pattern (generated from the same template) and ensure you have the correct VIs in memory without running them? (and producing loads of errors - these tests all logs any errors they produce to files)

I asked for the Guru's I didn't think I was going to the the Knights so fast!! Thanks Ben

---

Lacking Guru's you'll have to settle for me for now. 

If the defer makes it go slower the issue may indeed be the FP updates since the defer forces an extra update when set.

Is is slower if do the next two steps of hiding updating and un-hiding?

If you toss all MCLB code does it run fast enough to make you believe it is the GUI update that is hitting you?

Can you post image of your code as png or jpg?

How much data is in the MCLB?

This cloud has links to LabVIEW_Performance threads. Not sure if any of those threads ring a bell.

Please show us the code to get the most out of us.

Not sure about Q#2 but I would open them and keep a ref to each in array so that they are loaded when I need to run them. 

Ben

[James_W]

To clarify, The Guru's are not the Indian religious leaders, they are the LabVIEW experts on the forum. The old hands, architechects and the like. How you think that the 3 Knights cannot fall into the category of Guru I'm not sure. You Dennis and Christian lead the way when it comes to solutions.

I have attached a screenshot of on of the FP update subVIs, unfortunately, it didn't all fit on the screen due to my laptop monitor being ****. I normally work with a monitor attached. As only missing the controls and indicators, and the edge of the case structure, I'm sure you are not missing much.

I'll get back to you on the tossing of the MCLB code tommorrow, I've just though how to do that (should take half and how to do and benchmark, but they're trying to lockup the building here and the GUI doesn't run on my laptop's max resolution - poor design that needs improving with keyboard shortcut keys)

The MCLB displays 40 lines of data on the FP, it is emptied at the start of each run and adds a line test. This test sequence is a total of 5 extra lines, so 25 lines of data in the MCLB.

[Ben]

Why the inplace element struture?

Can you set any of those properties before the code runs (Cell justify, font color ?). Last I heard there was a bug hat forced LV to switch to the UI thread for every property in an expanded node as apposed to just switching once.

Since this code is mostly UI stuff setting it to run in the UI thread may help if thread swapping is the root cause.

Am I correct in understanding the MCLB has max 300 strings thats it? 

You don't have over-lapping indicators or decorations do you?

Ben

[F._Schubert]

I'm not sure if this helps, but since there is no clear idea, I throw it in the discussion. Some years ago with an even older laptop I encountered a big performance loss when coloring cells on a table (LV 7.1). I would guess that it should be ok on todays CPUs and a recent LV version.

Tweaking performance didn't work with my skills then. DeferePnlUpdates didn't resolve it (I think it had some effect, but too little), as assigning UI thread and changing to sync display didn't improve it. Benchmarking showed I lost time on operations that were not visible (cells that were not displayed).

So I suggest you to test wether not setting the color would reduce the time. My code was lost during an USB-stick failure and due to the bad performance I never tried to write it again, so I can't check the performance with todays posibillities.

Felix

[Ben]

---

F. Schubert wrote:

I'm not sure if this helps, but since there is no clear idea, I throw it in the discussion. Some years ago with an even older laptop I encountered a big performance loss when coloring cells on a table (LV 7.1). I would guess that it should be ok on todays CPUs and a recent LV version.

Tweaking performance didn't work with my skills then. DeferePnlUpdates didn't resolve it (I think it had some effect, but too little), as assigning UI thread and changing to sync display didn't improve it. Benchmarking showed I lost time on operations that were not visible (cells that were not displayed).

So I suggest you to test wether not setting the color would reduce the time. My code was lost during an USB-stick failure and due to the bad performance I never tried to write it again, so I can't check the performance with todays posibillities.

Felix

---

Thanks for that kick in the head Felix.

One of my developers had trouble getting a MCLB/Table to populate fast and ended up writing code to only show the displayed data and hid the non-viewed data. So we should file that away until we know a bit more about this situation.

Ben

[James_W]

Arghh...

The way I thought I was going to check up on this was to hide the MCLB off screen but keep it on the FP. I then read the MCLB values and write them to a file after testing, I thought this would be a way of testing without updating the FP for the user to see and so not incur an overhead. ARGH.

I can't benchmark this code

I'm running on a single core PC and I know performance increases with a multicore, more modern processor and more RAM, but to quote Ben or Altenbach in another thread.

"If it doesn't run well on a slow machine, it'll just run bad faster on a good machine." I'm trying to get it to run well on a slow machine so I don't have that issue.

Any architectural issues in the VI I posted that are obvious? (I have 4 different instances of this ech updating different cell sets and colour values if required.)