On Fri, Mar 6, 2009 at 11:55 AM, Guy Morton <g...@alchemy.com.au> wrote:
> JSON isn't binary but is more compact than XML. OTOH, parsing it may not be > as quick as XML. I haven't tested it yet in the Flash player but the post I linked to earlier claimed String.split (native to the player) is considerably faster than the native XML parser - at least in some cases. That's not hard to imagine, really. Either JSON or XML are text - both of which should benefit - even quite dramatically - from compression. > I wouldn't be manually zipping and unzipping data - a better idea would be > to enable GZIP on the web server and let the browser do the work (not that > that is trouble-free but still...). That sounds great and I'd like to pursue this as a few other people have made the same observation. In my tests, the gzipping wasn't happing in the browser prior to the data being loaded into the Flash player. I set the MIME type on the server to "application/gzip" or similar (I looked up the correct-sounding type at the time.) Can anyone point me to a working example of gzipping working 'passively' but effectively? Namely, that the Flash player gets uncompressed data even though the server sends the data compressed. That would be ideal. > Here: http://www.jamesward.com/blog/2007/12/12/blazebench-why-you-want-amf-and-blazeds/ > That should help you see what combinations are fast. Thanks - it's a great article. The author mentions gzipping but I haven't found the specifics. I suspect he's comparing processes without any compression.
