What does the profiler say about memory usage, is there any hard disk 'thrashing' going on during this period ?.
Also more details of your setup would help are the records large, what OS what SDK are you using.
OS X with v3.5 sdk
The returned data is 2.5MB, with the actual records being around 20 strings/numbers each.
I can't really see the result in the memory profiler, the object that contains the resulting data is only 20k according to the profiler. There isn't any hard disk thrashing going on.
I've tested this in a bare bones test app and it did not stall. There must be something about my app that is causing this problem, but the performance profiler is not picking it up, and tracing through the code everything looks fine, the code completes executing, but then there's 5 minutes of some mysterious processing going on.
Have you tried this with a release build of the project. Seems only a minimal amount of data so one would expect that no memory usage thresholds are being broken. Renderer's could be an issue as from your description its an issue after the data retrieval but before the display is updated.
Is there any processing that goes on after the collection of objects is received ? That would explain the slowdown. If there is a processing event that happens when the objects are received , you may want to investigate "Greenthreads" for Flex/AS3.
Have you got a large amount of bindable objects in there? Most of the nasty slow down I've seen when loading in large amounts of data is the databinding in Flex slowing down horribly by thrashing through the invalidation cyles repeatedly.
There can be many reasons resulting to this slowdown. Some of them could be, item renderers, trace statements if you are tracing the whole result set in debugging mode, data binding. You can comment pieces of your code to check which function or part of the code is causing this behavior.
THIS IS NOT AN EXACT SOLUTION THAT YOU ARE LOOKING....WHAT I FEEL IS YOU ARE GOING IN A WRONG WAY...
BUT YOU CAN THINK IN THE WAY I AM THINKING....
IF YOU ARE USING JAVA PLEASE KEEP LOOKING ABOUT LAZY LOADING LIKE CONCEPT...
Because If you are not showing 25k data @ one time it was a heavy waist.that is not best programming practice...I dont know other languages..But java has that Lazy loading feature in JPA JAVA PERSITANCE API....
thnx Happy cording...
2500 records is not a big dataset and the 15’ it takes to get them sounds reasonable. The problem here is not your service call, but whatever you are doing with those records after you get them.
If you post the code for the remote call’s result handler and the methods that handler is using, it will be a lot easier to figure out what is going on.