I was recently speaking with a colleague about the merits of
working with native XML across client and server tiers of a Flex
app vs. marshaling/unmarshaling XML to/from objects, and he
mentioned that in his experience, the performance of working with
ArrayCollections was much better than that of XMLListCollections,
up to an order of magnitude or better. So I Googled a bit, and I
This is a blog post that references some apparent comments
from someone from Adobe on this very issue, and suggests that E4X
may be a liability, at least from a memory standpoint. Between my
colleague's experiences and recommendations, and this blog post, it
raises the following questions:
1) Is there indeed a significant performance and/or memory
penalty for using E4X/XMLListCollections?
2) If the answer to 1) is yes, is this a design flaw, and
will be fixed at some point, or no?
3) If the answer to 1) is yes, then when would ever using E4X
be advisable? It seems the using E4X in general would be a
My particular reason I am asking is a fairly standard one. I
am trying to determine if it is wiser to orient client and server
architecture code to standard AS3 class objects, and marshal in and
out of xml when communicating between client and the server (i.e.
XML over the wire but objects, but after crossing the wire, marshal
out of XML to AS3 objects into ArrayCollections, and data bind the
UI to objects); OR, orient the client and server to native xml, and
use native XML not only across the wire, but E4X to marshal into
XMLListCollections and data bind to these objects instead. Native
XML structures and E4X on the client seem very attractive, as it
eliminates a lot of the trouble in having to code
marshaling/unmarshaling. But if it comes with a major
performance/memory price, then it is probably a bad architectural
idea. Customers don't much care about ease of development, they
want a stable, performant app.