If you are using ComboBoxes, Another trick you may want to consider is
using a custom renderer (not ComboBox) based on UIComponent that shows
the current data value + an editable indicator of some kind. Then use
the ComboBox only as the ItemEditor. I believe this will avoid the
overhead of the ComboBox until the user actually wants to edit that cell.
hth
Scott
Alex Harui wrote:
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
> >
> >
>
