This content has been marked as final. Show 4 replies
In the words of a top-notch flex engineer, Alex Harui, on this topic:
"I haven't done any formal measurements. E4x seems pretty fast to me.
XMLListCollection, though, adds overhead for changewatchers and if the data is static that may not be worth the cost. Also, I would expect that E4x queries that drill down levels are going to add up compared to "caching it" in a sealed class instance. And then there might be type conversion if your data contains numbers. The list classes are not careful about how often they query for a property which is a fast prop lookup on a sealed class and some probably-slower thing in XML.
But you can bet that any time I grab data off a server it'll be in e4x until I see that that is what is killing me."
Tracy, thanks for the response. Here's a blog post I found that comments on this, and actually is related to 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. I'd be interested to get your thoughts on this. Here's the blog post:
Let me know your thoughts -- it would be great to get a reply from someone at Adobe who could give a current "state of the state" regarding this -- it is a pretty significant architectural issue, and I'd love to definitively know the best design approach.
As usual, it will come down to your specific application, what is does, how it will be used, design and implementation cost-benefit analysis, etc.
The theoretical best-practice can be a poor business choice.
The e4x memory leak issue will be an interesting thing to watch.
Thanks for the response. I'm not speaking of anything theoretical here. I'm asking about a fixed performance difference between using XMLListCollections and ArrayCollections. If there is a significant cost to using XMLListCollections vs. using ArrayCollections, then for the purposes of designing a client-server architecture on marshaling in/out of data obects vs. XML, the XML/E4X is ill-advised. I don't know how it could be viewed otherwise. And if there are memory issues whenever E4X is used in data-binding as well, I'm not quite sure what the production purpose of E4X would be. I mean, it might be great for prototyping, but why would you base a system architecture on something that has a potential order of magnitude (referring to my colleague's claim here) performance hit, and a significant memory penalty?
Hence my desire to confirm this. E4X is dynamite for convenience. But clients don't much care about developer convenience, they want a solid, stable, performant application. And if this is true, it pretty much takes any use of E4X off the table, which would be a shame, because I'd much prefer to use E4X. Is there any way to contact Adobe with questions?