Slow Plotting

[Craig Leidholm]

I have a function that replots the screen when the user scrolls a plot. In debug mode, if I have a breakpoint just before the Replot() function, and quickly press F5 to continue, the plot replots in about 1 second (plotting 5 lines, ~150 pts/line using the PlotXY() function) - This is acceptable. If I remove that breakpoint, and just let it run, it takes 7-8 seconds to replot the same data. Created a release .exe to remove the debugger overhead - same thing. Suspended all timers callbacks before this function call - no help. Used ProcessDrawEvents() inside my Replot() function and outside as well and still no improvement. Any ideas what's going on and how to fix?

[Jeremiah Cox]

Hello Craig,
When you say that it takes 7-8 seconds to replot the data, do you mean that you program is unresponsive for 7-8 seconds or that it takes 7-8 seconds for the new plots to show up on the screen? You can use the Timer() function to determine the actual length of time your program spends in the Replot() function and then use it to determine which function is taking the most time. You would use code similar to the following:

T0 = Timer();
Replot();
deltaT = Timer() - T0; //deltaT now contains the time it takes to call the Replot() function in seconds (with 1 ms resolution)

I'm wondering if it actually takes 7-8 seconds to process your Replot() function, or if the plot update is being deferred (possibly because Smooth Update is enabled). You might try experi
menting with the graph attributes (disable Smooth Updating, disable rescaling, set ATTR_REFRESH_GRAPH to 1 or experiment with the RefreshGraph() function). The online help (press F1) has a good explanation of how graphs refresh and how to optimize their speed titled "Programming with Graph Controls" that you may want to check out.

Jeremiah Cox
Applications Engineer
National Instruments
http://www.ni.com/ask

[Craig Leidholm]

Thanks for the suggestions. Actually I am already using the Timer() func. both outside the function call and inside to try to find where the delay is. That's where I came up with 7-8 seconds (it's actually closer to 6.8 or 6.9 sec, but I thought that's a little TMI). I have found that the delay appears to be a for loop inside the RePlot() func, but can't explain why it's faster when I use a breakpoint before calling the func. For instance, I timed the for loop when no breakpoints were used, and found that each cycle takes ~1.5 sec for each of the five loops. But when using a breakpoint just before calling the func. the entire plot takes ~1.5 sec.

Also a good suggestion to check the smooth update and rescaling attributes. I have tried to optimize with
those funcs/parms, but have found that they have very little effect on my app because of how I'm plotting.

My main question is why my function plots the entire next screen of data at 1.6 sec if I have a breakpoint in my scrollbarCallback just before my Replot() func is called, and quickly press F5 to continue, whereas it takes 6.8-6.9 sec if I remove that breakpoint. The path of execution is the same whether I break or not, right? I would think that it would update faster if I remove the breakpoint since there's no delay in my hitting the F5 key. I have no vars in my watch screen - no overhead there. I have a fast PC w/ 256 MB RAM. And this app is not very resource-intensive. It seems specific to the CVI platform/environment or debugger.

What is LabWindows/CVI doing different in these two cases (w/ and w/o breakpoint)?

I hope this helps a light go on for someone. Thanks.

Craig Leidholm

[Jeremiah Cox]

Hello Craig,
Since you have tried a Release version and still experienced the same issue, I do not think it is related specifically to the debugger (as that code is removed from Release versions). However, the fact that your code runs faster when in Debug mode with a Breakpoint is quite strange. What type of machine are you testing on (multiprocessor)? Can you reproduce this issue on another machine? Also, what exactly happens in your "for" loop? You may want to post the contents of your for loop so that we can take a closer look at it (using Timer() inside the loop to determine the "slow" function would also be a good idea). Also, if you can create a small test application that reproduces this issue on multiple machines, we would be glad to test
it here (http://www.ni.com/ask >> E-Mail NI Engineers).

Jeremiah Cox
Applications Engineer
National Instruments
http://www.ni.com/ask

[Craig Leidholm]

As a follow-up, I discovered how to fix the slow plotting - SetSleepPolicy(). When I changed to none or some, the plotting was significantly faster, more like the plotting when using breakpoints that I mentioned in the original question. I imagine that when using the breakpoints, the debugger changes or ignores the sleep policy, allowing for the faster plotting. Anyway, all is well setting the policy to 'none' just before entering the function, and then setting back to 'some' just after.

Thanks for the help.

[Nastaran]

Hello,

I see the exact same problem but, with inserting tree items. I have a loop that builds tag name and other attributes required for a tree item and then it inserts the item in a tree and that's all this loop does! Please note that the tree does not have many items (about 50) either.

As Craig has mentioned, when I add a break point to the loop, the loop executes fast but, when I remove it, it takes forever to execute the loop. Unfortunately, "SetSleepPolicy" did not help in this case.

Any suggestions are appreciated.

[LuisG]

One thing I would do would be to check to see if I have any watch expressions. Whenever code is running very slowly ni the debugger, those are usually the culprit.

Luis

NI

[Nastaran]

Thanks Luis, but I had no items in the watch window at the time. I beleive that the application was corrupted for some reason, since starting a new project and readding all my files (same code!) helped resolve the issue. It is still interesting to me that the delay time was always about 7 seconds! Maybe this will make a light go on for someone in NI developement team.