"I feel the need… the need for SPEED!" [Seven simple, performance-boosting tweaks for common Silverlight/WPF Charting scenarios]


This blog has moved to a new location and comments have been disabled.

All old posts, new posts, and comments can be found on The blog of dlaa.me.

See you there!

Comments (7)
  1. cplotts says:

    Great blog post … and great addition to your data visualization demos!

  2. ejschoen says:

    For technical computing applications, it’s often not reasonable to restrict data plots to O(100) points.  Line and area plots for an application that plots acquired engineering data can typically be O(1000) points.  Even with a couple of thousand points, line and area charts show pretty good initial performance at this level, so long as the data points are themselves not displayed.  As currently implemented, there is an O(N^2) performance cost to changing individual values, but this can be optimized when the value changes are minimal and the axes ranges remain valid after the change.  I tweaked the code a little bit to test this, combining the AddRangeObservableCollection technique (with support for replacing individual values under and event-grouping transaction) with some minor optimizations to suppress the Storyboard overhead when the transition duration for data values is set to 0.  This improves performance significantly, but it’s still not as fast as simply recreating the plot from series, which is unfortunately very visually prominent.  

    I think there’s a lot of overhead in the DataPoint architecture that could be removed if you were willing to live without the fluid animations of the current charts.  It might also be possible to reduce some of the memory usage that the current implementation consumes. (I load 1400 data points into a enumerable of structures, each consuming 132 bytes (ie, <200KB), which when plotted, causes IE memory to expand by 30MB.

    Series without datapoints could be very efficient, but I’m not sure I would want to embark on creating a parallel type hierarchy to Series=>DataPointSeries=>DataPointSeriesWithAxes=>LineAreaBaseSeries<T>, however.  Any thought on how to refactor the implementation so that it would be possible to create line and area series with optional discrete datapoint rendering and optional animation?

  3. Delay says:

    ejschoen,

    Thank you for the very detailed comments! One of the things some other data visualization packages offer is a distinct kind of "fast line" series that uses some of the same optimizations you talk about (no animations, no points, etc.) in order to give good performance for scenarios with many, many data values. That’s something that we’ve talked about and may look into doing one day. The good news is that anyone can do that today by writing a custom Series – but I completely understand why you wouldn’t want to take that on yourself. :)

    I completely agree with you that there’s a non-trivial amount of overhead with the current DataPoint-based approach, but I also think that approach is a big win for typical scenarios with <= 100 points. And this is another reason that a parallel, dedicated series hierarchy seems interesting to consider. For what it’s worth, I’m working on something right now that isn’t directly related, but may provide some related benefits. It’s too early to tell quite yet, but it might get us to a kind of middle ground that improves the current situation noticeably – even if it doesn’t go all the way to enable all the extreme scenarios.

    I’ll try to share more about what I’m doing once it’s more settled. Thanks for your feedback and your patience!

  4. Cheers for the post and sorry about the slow reply.

    Re: "Tip: Use fewer data points"

    I have created 2 simple controls that I believe could help quite a few people with getting some more performance from your charts. They are just a simple IValueConverter and a sub class of CollectionViewSource which when used together will reduce the dataset that the charts will attempt to render. It is nice and simple and I think will help quite a few people.

    Here is the link to the post with the code:

    http://leecampbell.blogspot.com/2010/02/squeezing-out-performance-from-charting.html

    I hope you like it.

    Lee

  5. Delay says:

    Lee.Campbell,

    Great post, super stuff – thanks for sharing!

    FYI that I’ve added a pointer to my links page: http://cesso.org/r/DVLinks

  6. ejschoen says:

    Lee’s approach is a good one.  For some kinds of data, you can do better with a nonuniform resampling approach that preserves the general shape.  I’ve had good luck with line simplification using Ramer-Douglas-Peucker:

    http://en.wikipedia.org/wiki/Ramer-Douglas-Peucker_algorithm

    For use in a line or area chart, you’d probably want to suppress the individual datapoint elements in the chart, because the resulting simplified series is signficantly and nonuniformly resampled.

    I’ve been wanting Microsoft to embed this sort of option into WPF and Silverlight polylines to support data-dependent level-of-detail simplification.  It would allow developers to create technical data presentations without having to specifically manage LOD simplification for performance.

    Eric

  7. Delay says:

    ejschoen,

    Fantastic information, that’s just the kind of thing I said in my own comment to Lee’s blog post! (Except that I didn’t have a link to share, so thank you.) I’ve replied again to his blog to add a pointer to your comment.

    I’ve also added a note to my TODO list to look into adding something like this to the framework as you suggest. It’ll be a while before I have time, but at least it’s on the list now. :)

Comments are closed.