James Ward has a RIA benchmark app which is probably at least a little self-serving since he IS an Adobe Flex Evangelist but...still could shed some light on different transfer format speeds.
http://www.jamesward.org/census/ - Todd --- In [email protected], "Abyss Knight" <[EMAIL PROTECTED]> wrote: > > From my understanding is that AMF, because it is binary encoded, is > the fastest mode of transfer available. I've seen a couple links > around the web profiling AMF vs. JSON vs. XML and from what I've > worked on personally, the JSONDecoder is very slow, XML tends to have > a large transfer size, and AMF seems speedy. > > HTH, > -- William > > --- In [email protected], "Chris Hunter" <chunter@> wrote: > > > > On Tue, Mar 11, 2008 at 12:11 PM, Brendan Meutzner <bmeutzner@> > wrote: > > > > > > > > The best workaround I've found is creating different aggregations > of the > > > data being shown. A fair bit of functionality is involved in > defining and > > > switching up the datasets, and would really only make sense for > date based > > > datapoints. Concept would involve creating less granular datapoints > > > (weekly, vs daily) and show the weekly data when larger ranges are > being > > > displayed. Shorten the range, and switch up to show daily data, > and so > > > on... check out Google Finance for good examples on this. > > > > This is the approach we've taken on a set of graphs that can display > > everything from a few > > hours worth of data at 30 second intervals to a few years with a > > granularity of a week. > > > > Many of the documented recommendations for speeding up charts (e.g. > > removing the drop shadow) > > were very helpful as well. > > > > At this point, a lot of our lag seems to come from the process of > > incrementally fetching data > > as the user pans/zooms the chart. I'm curious if anybody has profiled > > returning chart data as XML > > vs JSON vs the binary formats and whether one of those approaches has > > a benefit in terms of > > rendering speed (or just transfer speed on the wire). > > > > Chris Hunter > > >
