SciChart® the market leader in Fast WPF Charts, WPF 3D Charts, and iOS Chart & Android Chart Components
I’ve been developing an application which monitors parameters such as pressure and temperature in real time over serial communications. The data is displayed with SciChart in realtime, the user can configure what is displayed, change the time periods being viewed and the sample time amongst other settings.
The performance problem I’m experiencing appears to be from the drawing to SciChartSurface. I have tried a number of different approaches though I’m not sure I’m using the most efficient.
I have 5 FastLineRenderableSeries and 5 corresponding IDataSeries<DateTime, double> with the DateTime used as the x axis. The serial comms running separately is on a cycle time of approximately 100mS. The sample time for data appended to the data series can be set between 0.5 and 2 seconds.
As a means to monitor the performance of the application I have a separate serial comms application running on a different computer listening and displaying the data, from this data streaming on the screen it is easy to see when the performance is slowing.
Initially I had the series scrolling from left to right with all new data causing the x axis VisibleRange to be recalculated. This gives a scrolling effect with the whole chart shifting to the left but concerned the VisibleRange recalculation was causing too much of a processing overhead I changed it. Now data starts from the center of the x axis and only recalculates the x axis VisibleRange when the series reaches the far right of the graph similar to the ECG example.
The results were the same every time data was appended without any x axis VisibleRange recalculated there would be a pregnant pause on the serial data around 400mS (this is proportional to the length of time running and number of series being displayed).
I also set it up to use FIFO series although I don’t want to lose data I thought I’d try it. This obviously just restricts the performance hit by limiting the buffer size and is not practical unless using an exceptionally small FIFO size.
Not sure whether it was the appending or drawing process I allowed the two to be separated. Allowing the user to stop when data is appended and manually trigger when a redraw is performed with InvalidateElement().
Initially I let the application run for a minute to store some data then prevented the addition of any more data. It was then evident triggering when a redraw was performed would cause the slowing of serial data.
Additionally I have tried the other performance tips and tricks with little effect. If this is the best configuration I will have to open up the sample time to 2 seconds and limit the buffer size using FIFO series as the application could be running for days at a time.
Let me try to answer some of these queries for you:
Batching appends – could not implement this (no examples I could make sense of).
Ok, most of the examples use this method. All you need to do is to call this API with an array of many points:
dataSeries.Append(IEnumerable<double> xData, IEnumerable<double> yData);
rather than this one repeatedly in a loop:
dataSeries.Append(double singleXValue, double singleYValue);
Inside the DataSeries.Append() call is a calculation to determine min, max, perform bounds checks etc… If you append an array with several points instead of point by point, you will see orders of magnitude speed improvements.
In particular take a look at the Performance Demo – this uses a buffer of 1000 points to append in batches, and is able to append hundreds of thousands of points per second because of this.
Another performance difference I’m noticing when I open the example project compile and run it the whole execution seems extremely slow where as if I run the example “Launch SciChart WPF Examples” from the installed link under Start button it seems very fast (particularly ECG Monitor, Oscilloscope and Spectrum Analyzer).
This is probably because you are compiling the WPF Examples in Debug mode or running with the debugger attached. SciChart outputs all sorts of debug information, and the CLR also appends debug symbols. Compiling and running in Release mode without the debugger attached will give you a performance improvement of 100-200%. Please re-try in release and without the debugger attached. If you still notice a difference in performance, let me know.
Although the large example project is an excellent way to help show its use I struggle to get my head round some of the MVVM examples. A combination of examples especially like the simplest ones used in MSDN Help used to demonstrate the basics of the class, method, property is ideal.
Unfortunately a chart control is a complex piece of API. There is no easy way to break this down into class by class, line by line like the MSDN docs do for the .NET framework. Similarly MVVM is a complex concept which really requires study in of itself. We try our best to present examples with single feature but even those require many parts, such as Data, RenderableSeries and Axes. For those that require API documentation there is a CHM file included with the trial download, and if you link against SciChart.dll in your install directory, you should see the API documentation in Intellisense as you type.
Let me know if you are able to implement Batch appends using the API above, and if that made a difference to performance.
Ok, sounds to me like you have a complex scenario and debugging the performance requires us to see some code. Is there any way you can get over to us a solution to reproduce the issues you are experiencing?
You say you’ve read the performance tips & tricks, so i assume you are doing, or have tried some of the following? Is there anything in this list which rings an alarm bell?
Please login first to submit.