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. 

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?

-Graham

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.