RE: [flexcoders] Remoting peformance for large lists
Have you run this in the profiler? It might highlight code thats running more often than youd think it should. Also I wonder if the non-responsive time is due to garbage collection, have you watched the task manager while the app is unresponsive (not that we really release that memory to the OS)? The fact that the time increases based on the references certainly makes it seem like a potential memory management issue. Dont have any other real ideas and dont really have time to run the tests myself, sorry! Matt From: flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] On Behalf Of Alex Cruikshank Sent: Monday, June 13, 2005 5:07 PM To: flexcoders@yahoogroups.com Subject: Re: [flexcoders] Remoting peformance for large lists 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 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.
[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: http://docs.yahoo.com/info/terms/ attachment: remote_performance.gif testRemoteObjectTiming.mxml Description: Binary data TestRemote.java Description: Binary data
RE: [flexcoders] Remoting peformance for large lists
Have you ready my large data articles? Probably explains whats 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: flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] On Behalf Of Alex Cruikshank Sent: Monday, June 13, 2005 3:15 PM To: flexcoders@yahoogroups.com 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.
Re: [flexcoders] Remoting peformance for large lists
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: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Alex Cruikshank Sent: Monday, June 13, 2005 3:15 PM To: flexcoders@yahoogroups.com 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
RE: [flexcoders] Remoting peformance for large lists
Take a peek a http://www.tomlink.net and look for his WebService / AMF comparison. You feed it the details of the request and it times how long it takes to crunch through the data. It is a very cool application. BTW if anyone on this list knows Tom I would love to get an email for him. Thanks, Jeff Founder Flex Authority http://www.flexauthority.com We are actively seeking contributors for the site. Have a sample that you want to share with the world? Send it to us! From: flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] On Behalf Of Matt Chotin Sent: Monday, June 13, 2005 4:29 PM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Remoting peformance for large lists Have you ready my large data articles? Probably explains whats 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: flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] On Behalf Of Alex Cruikshank Sent: Monday, June 13, 2005 3:15 PM To: flexcoders@yahoogroups.com 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.
