0 Replies Latest reply on Aug 26, 2007 7:03 PM by brado77

    XMLListCollection vs. ArrayCollection

    brado77 Level 1
      Hello,

      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 found this:

      http://blog.fastlanesw.com/?p=14

      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 liability.

      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.

      Can anyone speak definitively to this?

      Thanks!

      Brad