How can we improve the update performance for an XamDataChart using the following?
a. 15 ScatterLineSeries with 1 new data point added per second and data in an ObservableCollectionb. 10,000 - 40,000 data points per linec. No data point markers, no fancy line stylesd. Data is added to each series at random times during the 1 second interval (i.e., comes from a serial device) and also comes in a random order. e. These updates come in on 1 thread per data series and all updates to the observable collection are routed through the graph UI threadf. X axis is time the data was collected (i.e, cannot use LineSeries)g. The xamdataChart built-in zoom mini-map widget is located in the lower right hand corner.
This graph functions with good speed for about 1 hour and then becomes unresponssive. For example, if you zoom in when the graph has good performance, wait, and then keyboard up/down/left/right after 1 hour, it take 20-30 seconds to shift the zoomed in are by 1 keystroke.
The CPU after 1 hour was a flat 25% of a 4 core CPU machine. Our VS 2010 profiling showed that 75% or more of the time was spent in a UI rendering code (maybe due to refreshing the graph 15 times each second).
In general, if you want the chart to update less frequently, you can send collectionChanged events less frequently.
If your collection supports adding ranges and notifying about range changes (AddRange) that is one way of doing it. Although you can also implement a custom collection where you manage when and what notification event gets fired.
In general, the performance of the scatter line series can never be good as a category line series, because we can make almost no assumptions at all about the shape of a scatter line. You could select a random x,y value for every single item and we would have to render all those line segments.
Meanwhile, there are lots of optimizations we can apply to a category line series. So if you can possibly represent your data in that way, I would recommend it. We have discussed, in the past, adding a new scatter series type that assumes that all the values will be monotonically increasing in x, creating a line shape, rather than something that looks like a birds nest. These additional constraints would help make a scatter line more efficient to render.
If that sounds like a good fit, I'd encourage you to make a feature request, to help increase the priority of this item on our backlogs. I may be able to put a sample together as a "custom series" that could help with performance, but it wouldn't necessarily represent production ready code.
Do you have a sample project that demonstrates what you are trying to do? That would help to put this into context so we can evaluate what other options may be available to you.
Oh, and yes, the scatter series currently do use some dictionaries that are keyed on the collection items. The use these to improve the performance of some animation use cases. Is this particularly bothersome, or just something your had to adjust for?
Hope this helps!
-Graham
Hello,
Thank you for your answer.
If your data source is not randomly generated, but it is rather as you said “more or less the same”, the performance should be pretty good now – no need of further optimizations. Do you still have the issue standing, when you gave up the random data? If you check the link provided (the one to the forum), it says that optimization can be made by:
“… perform a smoothing function on the data before providing it to the chart” where this function makes the series line “being more “line" like.” – that means that if the data points have at least a bit of a dependency between them (means that they are not random numbers between 1 and 1000 so one point has value of 3 and the next has value of 898), the control should have high performance.
I will be looking forward to receive some feedback from you regarding the discussed matter.
Sincerely,
Ekaterina
Developer Support Engineer
Infragistics, Inc.
www.infragistics.com/support
Can we optimize how the data points are added to the graph?
Data points are added:- At the end of the list becaue each new data point has a larger time value than the last item in the data series list (i.e., no need to sort the list or put it into a dictionary). - A data point is not modified once it is in the list- Our data points are more or less the same (i.e., lines are not wildly random).This generalizes into an ordered ScatterLineSeries instead of a possibly random poly-line.
Of note, Infragistics puts the data into a dictionary internally which may or may not affect performance. Adding a data point two times will cause an exception of duplicate key found in a dictionary.I looked at the chart performance optimization help topic and will also try some of the suggestions.
http://help.infragistics.com/Help/NetAdvantage/WPFDV/2011.1/CLR4.0/html/xamDataChart_Chart_Performance.html
I have been looking into your question and this behavior is not unexpected, considering the test conditions that you have mentioned.
XamDataChart is highly optimized control, but still there are circumstances which can seriously affect the performance. The worst case comes with the random data usage. If you have a data source that contains of a list of million random elements and you measure the performance metrics with the same data after being sorted, the difference should be significant.
In the following link you will find a conversation between with a client who has very similar case to yours: ScatterLineSeries with thousands of random data points, that has an unsatisfactory performance:
http://blogs.infragistics.com/forums/p/47595/283799.aspx
Going through the forum you will notice that there are some performance optimization suggestions. They are described as well with some few other approaches in the following page of our documentation:
Please take a look at the provided samples and let me know if you have some more questions on the discussed topic.
You will
Is there a way to set the Infragistics XamDataChart to refresh itself every X miliseconds instead of on every data point added to the graph?
Lastly, we usually run these graphs zoomed all the way out to show the entire series data curve.