I'm trying to plot roughly a million data points (x,y) (floats) into a xamDataChart. When using a CategoryXAxis and LineSeries, the performance is excellent and zooming is smooth.
When using a NumericXAxis and a ScatterLineSeries, I am experiencing a significant loss in performance. This can be reproduced by adapting the "BindingHighVolumeData" sample.
Also, I am experiencing rendering artifacts when zooming deep into the graph:
Thes issues do not occur when using a CategoryXAxis.
I am currently evaluating to buy Infragistics DV for Silverlight for its stellar performance. However, I do need a precise x,y plot. As far as I understand CategoryXAxis will align my data points with a constant x spacing, correct?
Why is the performance of ScatterLineSeries so much worse? Is there a recommended way to draw a high performance xy line plot?
Hi,
There are unfortunately far less contraints on pure XY data rather than ordered category data that cannot regress to earlier x values from higher x values. We are always looking to make the scatter cases better, but because the data is less constrained it will always be far less efficient than using a category series.
So, if your data only ever has an increasing x value, you are far better off using a series with a category axis than a numeric x axis.
The CategoryXAxis will align your data points with a constant x spacing, but the CategoryDateTimeXAxis, will space them based on the date difference between the points, rather than spacing them all equally. This is a slight relaxation of constraints of the CategoryXAxis, so the CategoryDateTimeXAxis will likewise never perform as well as the CategoryXAxis, but its much closer in performance compared to NumericXAxis based series. CategoryDateTimeXAxis also doesn't assume your data is pre sorted by date, so there is a bit of a hit there, especially if you are updating the data with high frequency.
Nevertheless, you are much better off using CategoryDateTimeXAxis or CategoryXAxis if those match the requirements of your data. The complete lack of assumptions we can make about pure XY data make it much harder to retain interactivity when large volumes are thrown at the series.
That being said, if you can provide a sample with your scenario I can examine whether there is anything to be done to improve the x-y plot performance for your case. It may be useful if we were to add a mode to the scatter plots where the user could specify that the data was constrained to only increase in X, in which case the axis could behave more like CategoryDateTimeXAxis, but not necessarily be related to dates. Would that sound like a useful feature request?
I haven't seen that graphical distortion with scatter line before. Do you have a sample that reproduces it? Which version are you evaluating? As an additional note, there are many performance improvements in 11.1, so if you are running a previous trial version, you may want to grab the 11.1 version.
There was a performance fix that should be in the most recent version of 11.1 that should help scatter line performance, as the chart was doing too much work even though the markers were turned off. I don't believe the trial version has this fix though. If you can provide a sample of the poor performance I can tell you how it performs with the latest version though.
Hope this helps! Let me know if you have any other questions.
-Graham
Hi Graham, thanks for your fast feedback. I have attached a sample repro for the artifacts encountered when using a NumericXAxis. Let me know if you can reproduce the issue. The version I am using was downloaded just yesterday, so I assume it's the latest.
CategoryXAxis actually is an option in most scenarios, however it results in a loss of visual accuracy in my case. CategoryDateTimeXAxis is a decent choice, however not all data is suited to be transformed into a DateTime, so I'm a bit concerned here.
I do have floating point x/y coordinates (think of a simple waveform) that are guaranteed to be in correct order. Transforming all x values into a DateTime will result in a precision loss and is slow and cumbersome to do.
Your feature suggestion (OrderedNumericXAxis) is exactly what I would wish the control offered out of the box. Is it likely this will be implemented? I think its a fairly common scenario.
Hi Graham,
Hope you received my sample? I should add that I observed some other odd behavior, which causes me to believe that the performance issues might not be related to rendering alone. I have tried cutting down the number of data points by factor 10 by using my own resampling, you can achieve the same by simply picking every 10th acceleration sample. With the sample data I sent you, this results in 15.000 data points, something that should be well manageable for the chart.
Even then zooming and panning performance in the zoomed out states (with lots of data visible) was terribly slow. It got reasonably fast when I either resized the chart to something smaller than 1920x1080 or zoomed in, so that only a few hundred data points were visible.
My chart does allow horizontal zooming only. If I select a rectangle area to zoom into, even the time from making the selection till the chart gives a visual response (greying the unselected area) takes a noticeable amount of time instead of being instant. Releasing the selection to let the chart zoom in takes another few hundred milliseconds. I think there's some room for optimization here too.
On a side note:My dara is typically in (-1,1) on the y axis. Would you expect some different performance characteristic if I rescaled my data? Obviously this shouldn't help, but it might be that there are some implicit assumptions about typical data ranges and I'm just falling off the edge here.
Hi Graham
I did conduct same basic profiling to get a feel for the headroom we have for optimizations. I think you maybe mixed something up in your last paraghraph: CategoryDateTimeXAxis does a sort each time it renders, whereas CategoryXAxis does not.
Here's a profiling trace from CategoryDateTimeXAxis while panning/zooming in the graph:
You can see that rendering the series takes as long as rendering the axis. In fact, most of the time is spent in CategoryDateTimeXAxis InitializeActualMinimumAndMaximum (see the trace).
In comparison, here's what it looks like for CategoryXAxis (I have some other axis with a lot less data, thats why you do also see the other ones) for a lot more re-renderings:
Hope you can fix this issue.
Regards,
Johannes
Johannes,
I haven't had the opportunity to look at your sample yet. But if you are seeing a large potion of time being spent in GetSortedIndices I would imagine you are updating your data in real time? (i.e. changing the values on some interval?)
If this is the case, you will currently have issues with the CategoryDateTimeXAxis. As i said, the DateTime axis does not currently assume your data is presorted or that you will maintain the sort, so if you update the data, it has to resort the date time column before rendering. It doesn't do this every time, but it currently has to if you change the data.
This makes the axis, in its current state, difficult to use if you have both large quantities of data and are updating it in real time. Could you confirm for me that this is the case?
As I alluded to before, I believe we need to remove the assumption that the data provided to the date time x axis is not pre-sorted in order to properly support the kind of scenario you are trying to implement (assuming I'm interpreting your profile correctly). The issue, though, is that this would be a breaking change for those using the axis with less volume or without realtime updates who are depending on the sort occuring.
Unfortunately, detecting whether the data is presorted would be just as time consuming as doing the sort! ;-)
Perhaps we can add a property whereby you can indicate that you will keep the data sorted by date time, which will disable any of the sorting behaviors in the axis, do you think this would suit your needs?
No problem. My data is pre-sorted and I am NOT updating the collection on realtime. In fact I'm binding to an array of immutable data.I assume there's a bug hiding somewhere in the chart that causes a re-sort even if it is not necessary.
I saw you are using Linqs orderBy which I think to remember uses a stable quicksort (n log n). You mght opt for a radix sort to sort in n (dont know if that helps much) or use some parallel sorting when there are lots of data points.
Anyway, biggest problem is that it sorts when it shouldnt.
Its definitely not supposed to be resorting unless the data has changed. So either you've discovered a regression bug or something in the way you are using the chart is causing it to resort the data when it doesn't need to. I'll look into your sample tomorrow morning and see if I can determine what might be going on.
The fix has been checked in, so barring any unforeseen circumstances you should see it in an upcoming service release. I'll also check your scenario against the new volume release we are working on and see if there is any other tuning we can fit in.
That's grand. Let me know when I can expect this to be fixed. I think this should really make the chart performant enough for my purposes.
Bug number is 102640
It looks like there has been some sort of regression which is causing the axis to resort its column every time the zoom level changes. I'll get back to you with a bug number.