This content has been marked as final. Show 4 replies
You can calculate elapsed time by using the getTimer() method.
It has become apparent the there are performance problems with directly using e4x xml data models in large dataGrids.
the perferred practice is to get the data as resultFormat="e4x" xml (this avoids the parsing that happens with the default resultFormat="object"), but to then process that xml into an ArrayCollection of stronly typed VOs. then bind the DG or list or Tree to that ArrayCollection. Accessing properties of strongly typed objects is significantly faster than hitting the e4x xml nodes directly.
Thanks for the reply!
What you are describing (processing the xml into an arraycollection) is exactly what I'm doing. It turns out I was wrong, the instantiation (sp?) of ~2000 objects is very, very fast.
We are getting a freeze-up when retrieving very large result sets from a webservice call. The application is responsive while the data is coming down. The freeze is just at the end of process. My guess is that it's the browser handing off the xml to Flash that takes a second.
I suppose the answer is to use a paging mechanism. Grab records in batches of 100 or so to give the appearance of not being locked up.
Anyhow, thanks again for the reply.
In-memory processing in FP9 IS very fast. The performance bottleneck is in the rendering of the ui, the is why the end part is so slow. That is why spending the time to peocess the e4x xml into stronly typed objects is worth it. You want to give the rendering process, where it grabs the data from the model, as much help as possible.
Now, DataGrid sort of "pages" itself anyway, as far as ui rendering goes.
Google this if you haven't yet. Many people have discussed Flex performance on many different levels.
Oooh, I think I missed something you said. Do you think it would be faster to wait to set the data provider until after I've filled the array collection?
I'll give that a try - it would be super-simple to do.