I don't think there is a loitering objects computation in Scout. Plus, even in FlashBuilder, you can't always use Loitering Objects to solve a memory leak problem. There are two kinds of memory leak scenarios described on my blog [2]. Loitering objects only helps with one of them and there have been many occasions when I've had the "other" scenario.
Fundamentally, loitering objects compares two memory snapshots and reports which objects were in the second snapshot that weren't in the first one. Loitering Objects computations are therefore useless when objects are supposed to get tossed and re-instantiated. Like if you refresh data every 10 seconds. If you had 8 data items, threw them out, and created 8 new ones, Loitering Objects says those 8 are loitering. Which they are, but that isn't a leak. So first, what is your scenario? Is it one of those, "I leave the application on overnight and when I come back it has crashed from being out of memory"? Or "If users perform this sequence of steps often enough, the app crashed from being out of memory". Then try to look at the Scout data. You may have to write down one screenful of the allocations and manually compare to what you see a few minutes later, but if memory is growing, the amount of memory allocated is also growing and the amount of memory allocated to certain classes or objects is growing and probably shouldn't and you'll have to keep digging until you find out what it is. When I can't use Loitering Objects in Flash Builder, that's what I have to do: I manually compare two memory snapshots. Painful, but works every time. One other thing: If your app is too big to be profiled by FlashBuilder, it is a hint that your app could use better modularity. Unless the sequence of steps to reproduce the memory leak is extraordinarily complex, you should be able to execute the few steps to get directly to the memory leak scenario without allocating nearly the amount of objects that you might otherwise do if you are actually using the application. Think of a ship with the sealable doors to stop the ship from sinking when one compartment springs a leak. Proper modularity should, in most cases, allow you to disable parts of the app to help eliminate whole sections from being the culprit of a memory leak, and thus reduce the allocation count to the point where FlashBuilder can handle it. Also, there is a "flaw" in the garbage collector in Flash in that the mark and sweep algorithm doesn't really know what pieces of memory are memory pointers and what is data. I've never seen it happen, but they tell me that the more memory you allocate, the more likely you will get memory pointers that look like your data and that can fool the collector into not collecting objects that should be free. Also, the collector is supposed to be "opportunistic" in that it is supposed to stop collecting if too much time has gone by in the frame, so in theory, it is possible to "out run" the GC by creating objects faster than it can find and collect. BTW, the LocalConnection hack supposedly still works and supposedly fully cleans everything, so you might try that if you haven't. But again, it can still be fooled by data looking like pointers. HTH, -Alex [2] http://blogs.adobe.com/aharui/2008/09/using_the_flex_builder_3x_prof.html On 9/4/14 2:40 AM, "DarrenEvans" <[email protected]> wrote: >Yes, read that, it was one of the first ones. Gives a reasonable overview >on >how memory is allocated but doesn't really get down to the details of >working with the results Scout gives to locate leaks. > >In our application's architecture we have a common framework and then the >main application sits on top of this. I had more success getting a very >basic application (sitting on the framework) compiling in FlashBuilder and >then using the profiler in that so I could fix any framework leaks first. >The loitering objects functionality seems a bit more useful (although not >100% correct) and we have found the biggest part of the leak in the >framework code using those tools. > >I cannot use the FlashBuilder profiler for our main Application as it's >too >big for it to handle. It's REALLY slow and normally crashes after a few >minutes. So...... back to Adobe Scout to work out where the memory is >going >in the application. Is there anything like the loitering objects >functionality in FlashBuilder profiler? > > >Alex Harui wrote >> Have you read this: >> http://www.adobe.com/devnet/scout/articles/scout-memory-profiling.html > > > > > >-- >View this message in context: >http://apache-flex-users.2333346.n4.nabble.com/Using-Adobe-Scout-to-locate >-memory-leak-tp7770p7853.html >Sent from the Apache Flex Users mailing list archive at Nabble.com.
