Donovan Preston wrote:

This is very amusing. It boggles my mind, really. The reason I used XML for the Canvas RPC mechanism rather than plain text was because in theory an XML parser written in C should exhibit better performance than a text parser written in pure actionscript. In fact, all the other work I had ever done with Flash used a plain old text format, and switching to XML was supposed to be an optimization.

The problem here is that you need quite a lot of non-native code to extract data from the pseudo-DOM that the XML parser returns while you need very little to make sense of an Array returned by the String.split method, which is written in C too. So String.split() (native) + myarray[n] (non-native) is likely to be faster than XML.parseXML() (native) + myxml.childNodes[n].firstChild.attributes.etcetc (non-native)... An optimization rule of thumb that is more effective in Flash than in other environments is: the less code you write, the faster it is, unfortunately this often makes for poorly readable code that tends to give too much for granted.

With a plain text format, there is the additional difficulty of supporting nested structures (which is simple in XML). Some of the encodings include dicts and lists.

Choosing the right format for keeping the features while not losing speed will be a cool challenge, I hope I manage to dedicate some more time to it once I get to play with Canvas a little more, for today I am just happy to know I can rely on it as it won't necessarily crash my browser, shame on the linux version of the plugin anyway, it has always been sadly behind its Win/Mac counterparts in many ways. ciao ste