Hi Matt, I have read (and now re-read) your excellent large data articles (which are now well established within the Flex literature's cannon). This exercise was an attempt to squeeze all the performance out of our requests before we implement paging and to try to establish an optimum page size. I wanted to try to make some addtional improvements because I was afraid that (assuming performance declined linearly) loading small chunks of data would still make that application to unresponsive. This seems to be a poor assumption in the case of our actual problem.
I'm still curious as to why deserialization performance decreases non-linearly with item count (but not item size), why common object references affect the load time, or why there is a significant period *after* the resultHandler during which the client becomes unresponsive. Any help with these questions would help set my mind at ease. Thanks, Alex On 6/13/05, Matt Chotin <[EMAIL PROTECTED]> wrote: > > > > Have you ready my large data articles? Probably explains what's going on as > far as deserialization and whatnot (and potential approaches that may or may > not be applicable to charts). > > > > http://www.markme.com/mchotin/archives/cat_data_management.cfm > down at the bottom. > > > > Matt > > > > ________________________________ > > > From: [email protected] [mailto:[EMAIL PROTECTED] On > Behalf Of Alex Cruikshank > Sent: Monday, June 13, 2005 3:15 PM > To: [email protected] > Subject: [flexcoders] Remoting peformance for large lists > > > > > Hi all, > We're having some peformance problems on the client side when loading > large lists of object graphs through our remoting inteface. I've > written a simple test case to characterize the problem (the mxml file > and remote object are attached), and I'm seeing some behavior I can't > explain. I would appreciate any help anyone can provide understanding > the problem or providing work-arounds. > > The time between the remote method call and the resultHandler of the > call grows linearly with list size and/or object size as you'd expect. > We're also seeing a period of time after the result handler where the > application becomes unresponsive. This is what I can't explain. This > mystery time increases non-linearly with item count and seems to > increase greatly when items in the list reference other objects (even > if they all reference the same instance). I've traced data from > within the result in the resultHandler, so the action script objects > seem to be fully serialized by the resultHandler, so the clients > peformance after the resultHandler doesn't seem to be directly > hampered by object loading or creation. > > The attached graphs show the results of my tests. In each graph the > time until the result handler is in orange, the time after the result > handler is green and the sum of the two is blue. > > TOP LEFT: Load time per item where each item contains a map with 5 > entries. Note that the mystery time (green) increases non-linearly, > and (excluding the spikes) the orange increase linearly. > > TOP RIGHT: Load time per item, 10 entries. The orange lines slope > increases as you'd expect since the size of the objects have increased > by ~80%. The green line is identical to the graph of items with 5 > entries. > > MIDDLELEFT: Load time per item, 20 entries. Again the orange line's > slope increases as expected. The mystery time remains the same. > > MIDDLE RIGHT: I modified the remoting code to create a single parent > item and give each item in the list a reference to it. I then created > a second parent object so that each object would have a reference to 2 > parent objects (but only a single instance of each). I overlayed the > graphs so that the scales matched (each item had 10 map entries and > the bottom lines are test graphed in the TOP RIGHT). Note that adding > the one reference increases the mystery time by nearly 100% and adding > the second reference increases it by 150%. > > BOTTOM LEFT: Load time per map item, 1000 items. Holding the items > constant, you can see that the mystery time holds constant after a > certain point, and the load time (orange) increases linearly with > object size as expected. > > BOTTOM RIGHT: Repeated calls for 0 items. This is a control to > eliminate the possiblity that multiple calls or the graphing was > responsible for the slowdown. > > Thanks, > Alex > Carbon Five > > > ________________________________ > Yahoo! Groups Links > > > To visit your group on the web, go to: > http://groups.yahoo.com/group/flexcoders/ > > To unsubscribe from this group, send an email to: > [EMAIL PROTECTED] > > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
