If your resultFormat is Object, I'm pretty sure all of the XML has to be parsed into objects before the busy cursor goes away and the result handler fires. I would expect noticeably faster response if the resultFormat is e4x.
But as Scott has found out, memory utilization of XML collections is much higher than objects in ArrayCollection. I spent a week studying the issue and we've made some improvements in Moxie, but it XML will always take more memory and fetching properties out of XML is measurably slower than fetching properties out of objects. Thus, you have to trade-off how much XML data you're getting, the time to convert it to objects and the time you'd spend accessing it if you didn't convert it. I don't know if anyone has created a background task that will convert XML to objects, but I've been thinking about doing that one of these days. That would allow you to show more than a busy cursor, but will delay the total time until you see the data in the views, so there will be another trade-off. Another twist would be a custom collection that converts the XML to objects as they are fetched from the collection. You should see the busy cursor "freeze" the moment it tries to do the xml conversion to object. Then it should go away and there will be another pause while the DG builds the renderers. If you've got lots of comboboxes, you'll definitely feel it. A quick way to compare it to sub-out the comboboxes for the default renderer and see if you can tell the difference. I'll put in trace statements and call getTimer() in "enterFrame" events as way to measure where your time is going. The Moxie beta due out next week has some profiling capability that will help you too, but optimizing DG performance will have the biggest payoff. ________________________________ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of j_lentzz Sent: Friday, September 28, 2007 6:54 PM To: [email protected] Subject: [flexcoders] Re: HTTPService Performance Issue - very slow Yes, I am using a result handler. The timers I've used have timed from when the result handler gets called until the time I finish processing all the data and then let the Flex stuff do its thing. This time is very small and I can't start timing any sooner than the result handler. I'm sure using extended components vs the heavy combobox would help, but I'm confused about why the busy cursor is staying on so long. Once it goes away, the complete screen draws nearly instantly. Is there anything to be done to speed the processing of the incoming data until the result handler is called? Thanks a bunch, John --- In [email protected] <mailto:flexcoders%40yahoogroups.com> , Scott - FastLane <[EMAIL PROTECTED]> wrote: > > oops... sorry about the prior message. Doh! > > It has also been my experience that rendering is usually the > bottleneck. See this post on my blog <http://blog.fastlanesw.com/?p=25 <http://blog.fastlanesw.com/?p=25> > > for an example of the difference a UIComponent based renderer can make > over containers. > > hth > Scott > > Tracy Spratt wrote: > > > > In my experience, the rendering of the UI is the bottleneck, not the > > data transfer. > > > > > > > > Use timer and the result handler function to time the actual data > > transfer. You ARE using a result handler, and not binding directly to > > lastResult, right? > > > > > > > > Are your item renderers built on containers? If so, you need to move > > to extending UIComponent instead. See Alex Harui's blog for a full > > explanation why, and for many examples. > > > > > > > > Tracy > > > > > > > > ---------------------------------------------------------- > > > > *From:* [email protected] <mailto:flexcoders%40yahoogroups.com> [mailto:[email protected] <mailto:flexcoders%40yahoogroups.com> ] > > *On Behalf Of *j_lentzz > > *Sent:* Friday, September 28, 2007 2:11 PM > > *To:* [email protected] <mailto:flexcoders%40yahoogroups.com> > > *Subject:* [flexcoders] HTTPService Performance Issue - very slow > > > > > > > > Hi, > > > > I've got an app getting data from a server to populate a screen with > > 3, text inputs, some radio buttons and a data grid. With some data, > > it is taking almost a minute to save and refresh the scren. The data > > grid seems to be the issue. It contains many comboboxes. I've read > > that these are very slow if too many appear in a datagrid. I see the > > last data leave the server and I have timer marks for when I start my > > processing of the returned data (populating the arraycollection for > > the datagrid - I'm using the default resultFormat of Object) to when > > I'm done and just waiting on the screen to display it. The processing > > time I'm getting from the timers is very low (1/2 sec or less). > > However, I'm seeing the busy cursor staying on the screen for almost > > the complete time I'm waiting. Once the busy cursor leaves, the > > screen appears almost instantly with data. The docs say that the busy > > cursor is displayed until the class completes loading data. So is the > > bottleneck on the Flex side (the loading of the data from the > > HTTPService) that I can't access? Or is my datagrid full of > > comboboxes the issue, even though the busy cursor is staying on the > > screen. > > > > Any guidance would be appreciated. > > > > Thanks, > > > > John > > > > >
