Measurement Studio for .NET Languages

cancel
Showing results for 
Search instead for 
Did you mean: 

High CPU usage while trending on a waveformgraph

Hi,

 

I evaluate some graphing SDKs and NI MS is one of them. The test case is the following:

 

Update rate: 4Hz

Number of Points on each update:5

Number of Points/Plot: 144000

Number of Plots:10

 

After one hour, the WaveformGraph uses 100% CPU on my PC (Core Duo 1,8GHz). Is this kind of a "expected behaviour" because the test case is too challenging?

 

I have to ideas how to tackle the high cpu load:

1. Use a smaller data type for plot data. Currently, I use doubles but floats would be sufficient. I thought about using PlotWaveformsAppendMultiple instead of  

PlotYAppendMultiple and using float as <TData>, but I read in the forums that MS is using doubles internally anyway, so that it would bring no performance gain. The statement is from 2006. Is this still true?

2. Only draw every 100th sample or so. Another guy who had similar problems did this here. A NI guy also said in this thread that "The problem has been fixed and will be available in the release of Measurement Studio after 8.1.". So I wonder whether this kind of interleaved sample painting is allready implemented?

 

Any other hints how I could speed things up are highly appreciated.

 

One last thing Id like to know: How can I measure the time the control needs to redraw itself? I made a wild guess and assumed that the "Invalidate" event is fired just before the controls is drawn and "Paint" is fired directly afterwards. The code I use for measurement looks like this:

private void onInvalidate(object sender, InvalidateEventArgs args )
{
stopWatch2.Reset();
stopWatch2.Start();
}

private void onPaint(object sender, PaintEventArgs args )
{
this.drawtime = stopWatch2.Elapsed;
stopWatch2.Stop();
}

 

Is this reasonable?

 

Regards,

Janosch

0 Kudos
Message 1 of 7
(4,777 Views)

One more thing I dont really understand: As soon as HistoryCapacity = "Number of Points", adding new points to the chart is more than 200 times costlier than before. If the internal buffer is realized as a ringbuffer, this should not happen.

 

DatePlotYAppendMultiple(ms)HistoryCount
08.09.2009 20:120.2862405341439250
08.09.2009 20:1217.522016871440000
08.09.2009 20:1280.836144891440000

0 Kudos
Message 2 of 7
(4,756 Views)

Hi, could you please post your example?

Which Version of MS are you evaluating?

 

M. Brauner NIG

0 Kudos
Message 3 of 7
(4,750 Views)

Attached is a VS2005 solution which is a subset of our testing framework. Due to the framework design, there are minor inefficiencies here and there, but the performance hit should only be small. The project compiles but when I run it I get a license exception. I guess that has something to do with the fact that I just copied our testing framework project directory and deleted the stuff which is realted to other charting SDKs.

 

Im evaluating 8.6.0.192.

0 Kudos
Message 4 of 7
(4,746 Views)

What about the memory usage? I think you pretty much surely run into memory-problems when using

"AppendMultiple" for a long time. Didi you observe Memory?

 

 

M. Brauner NIG

0 Kudos
Message 5 of 7
(4,731 Views)
The virtual memory peak is about 440M, which should not be an issue (my PC has 2GBs). See the attached logfile for more information. I dont really see why I may run into memory-problems by using AppendMultiple. I set a fixed buffer size (HistoryCapacity) for every plot. If the buffer size is not big, then I should be able to call AppendMultiple as often as I want.
Message Edited by binford3000 on 09-10-2009 06:40 AM
0 Kudos
Message 6 of 7
(4,728 Views)

There is some minor progress on that issue. I changed "JoergB's" MyPlot class to make it work together with a trending WaveformGraph. The Performance is far better than the standard WaveformPlot class. MyPlot basically skips X points before they are painted on the screen. Id did some measurements setting the precission to "1" meaning that for every pixel on the x-axis there is only one data point used from the history buffer.

 

But the problem of the performance hit as soon as the buffer is full still remains. I dont see why adding new points + removing old ones is so costly. This behaviour leeds to a (unnessecary) high cpu load which is not acceptable for us.

 

One last thing Id like to know: Whenever you are invalidating the graph, are you invalidating the whole graph or only the part which needs redrawing? My measurements suggest the former. Is this right?

 

 

P.S. I hope the attached project works. I couldnt test it because I get an "unlicensed" error.

0 Kudos
Message 7 of 7
(4,693 Views)