Macromedia Flash Server - My friend spike...

This is Interesting: Free IT Magazines  
Home > Archive > Macromedia Flash Server > April 2005 > My friend spike...





You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

Author My friend spike...
Simon Lord

2005-04-23, 2:45 am

Evening all, I've been working with RSO's and datagrids for a few
months now. Still learning but for the most part I think I'm over the
basics. The issue now is this amazing SPIKE in CPU usage when the
client side sync's up or when the datagrid redraws the dataprovider
culled from the RSO. I don't know because I haven't worked backwards
yet to see which one is inviting SPIKE into my app.

One of the tips I think I read was that the datagrid should just have
all it's data removed, turn the RSO into a new dp and redraw the
datagrid. I've done that but SPIKE is still here.

Is there something I should look into to reduce the SPIKE's? I have
the FCS bible here, f there is a specially poignant chapter to read
then just point it out and I'll jump ahead to it.

Sincerely,
Simon


=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------

To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm

Jayson K Hanes

2005-04-23, 2:45 am

Simon, I assume you mean client-side flash?=20

Oh right.. you mean.. you're using the FLASH player or plug-in?

Ah. Mystery solved.

Glad I could help!

-Jayson

> -----Original Message-----
> From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org [mailto:flashcomm-
> bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org] On Behalf Of Simon Lord
> Sent: Saturday, April 23, 2005 12:45 AM
> To: flashcomm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
> Subject: [FlashComm] My friend spike...
>=20
> Evening all, I've been working with RSO's and datagrids for a few
> months now. Still learning but for the most part I think I'm over the
> basics. The issue now is this amazing SPIKE in CPU usage when the
> client side sync's up or when the datagrid redraws the dataprovider
> culled from the RSO. I don't know because I haven't worked backwards
> yet to see which one is inviting SPIKE into my app.
>=20
> One of the tips I think I read was that the datagrid should just have
> all it's data removed, turn the RSO into a new dp and redraw the
> datagrid. I've done that but SPIKE is still here.
>=20
> Is there something I should look into to reduce the SPIKE's? I have
> the FCS bible here, f there is a specially poignant chapter to read
> then just point it out and I'll jump ahead to it.
>=20
> Sincerely,
> Simon


=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------

To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm

Simon Lord

2005-04-23, 2:45 am

You mean there is a known issue with the plugin (which is the delivery
method - yes).

Well, my current solution is to stick the datagrids into their own
popup managers. That way when the window object is not open the
datagrid isn't either and the CPU drops back to sub 5%. Which suggests
that the datagrid is to blame in the spike since the sync still happens
even though the datagrid isn't around.

Any third party datagrid components? Did Grant Skinner mention one
would ship with his set?


> Simon, I assume you mean client-side flash?
>
> Oh right.. you mean.. you're using the FLASH player or plug-in?
>
> Ah. Mystery solved.
>
> Glad I could help!
>
> -Jayson
>
>
> =-----------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com
> =-----------------------------------------------------------
>
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>
>

Sincerely,
Simon


=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------

To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm

Jayson K Hanes

2005-04-23, 2:45 am

I guess I was trying to convey, tongue-and-cheek, that.. components
suck.. and yes.. flash is slow.. and yes, there *might* be little you
can do about it.

Sorry Simon.. there isn't a breathalyzer on my pc :-/



Sorry I can't help more ATM

GL

-Jayson

> -----Original Message-----
> From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org [mailto:flashcomm-
> bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org] On Behalf Of Simon Lord
> Sent: Saturday, April 23, 2005 1:35 AM
> To: FlashComm Mailing List
> Subject: Re: [FlashComm] My friend spike...
>=20
> You mean there is a known issue with the plugin (which is the delivery
> method - yes).
>=20
> Well, my current solution is to stick the datagrids into their own
> popup managers. That way when the window object is not open the
> datagrid isn't either and the CPU drops back to sub 5%. Which

suggests
> that the datagrid is to blame in the spike since the sync still

happens
> even though the datagrid isn't around.
>=20
> Any third party datagrid components? Did Grant Skinner mention one
> would ship with his set?
>=20


=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------

To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm

Brian Lesser

2005-04-23, 5:45 pm

Hi Simon,
Yes, check out the beginning of chapter 15. There are essentially two
strategies: 1. drop and replace the data inside the DataProvider with
each sync. 2. use the information object array passed into onSync to go
through the DataProvider and update individual slots. For large lists
where the number of actual items changing at any one time is relatively
small method 2 should save a significant amount of CPU. However, the
DataGrid itself uses more CPU in comparison to List. So I'm told
another approach is to create a cell renderer for the list that renders
"columns" in each row. I have not done that so can't provide a good
example.
Yours truly,
-Brian

Simon Lord wrote:

> Evening all, I've been working with RSO's and datagrids for a few
> months now. Still learning but for the most part I think I'm over the
> basics. The issue now is this amazing SPIKE in CPU usage when the
> client side sync's up or when the datagrid redraws the dataprovider
> culled from the RSO. I don't know because I haven't worked backwards
> yet to see which one is inviting SPIKE into my app.
>
> One of the tips I think I read was that the datagrid should just have
> all it's data removed, turn the RSO into a new dp and redraw the
> datagrid. I've done that but SPIKE is still here.
>
> Is there something I should look into to reduce the SPIKE's? I have
> the FCS bible here, f there is a specially poignant chapter to read
> then just point it out and I'll jump ahead to it.
>
> Sincerely,
> Simon
>
>
> =-----------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com
> =-----------------------------------------------------------
>
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm




=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------

To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm

Sponsored Links






Free braindumps | Software forum | Database administration forum

Copyright 2003 - 2008 webservertalk.com