Thanks people.
After a wee bit more investigation and hair tearing, I ran my app using
the flash 8 beta player, instead of flash 7, and the memory problem has
gone. One test that was rather telling was that forcing the app,
running flash7, to reload a huge chunk of data over and over again would
quickly balloon memory usage. Leaving the app for a while would cause
Memory usage to go down, but virtual memory would not change. Flash8 on
the other hand would reclaim the memory every time the request was sent
and then dereferenced.
Read below to clear a few things up, or indeed confuse you further, for
anyone who doesn't have the luxury of using flash 8 and would like some
insights into the mad world of flash player 7 garbage collection, scope
chains and references.
Daniel Wabyick wrote:
Two things:
1) Flash will allocate itself a large chunk of memory, but this does
not necessarily mean a "leak" in my opinion. If you run the 1st loop,
if it truly increments indefinitely, you have a leak. Otherwise, Flash
is just allocating a lot of memory, probably because you used a ton in
one frame and it didn't release it. The second test probably gave it a
chance to release, so the heap didn't get so big.
I was watching virtual memory size and memory usage in windows task
manager. Behaviour was pretty consistent with a memory leak - virtual
memory got up to a gigabyte after enough xml parsing was done. It wasn't
freed up when app was minimized, which is one way to force the player to
garbage collect, so i've heard. I think you are right about the second
test - something about the way the stage works was causing the memory to
be freed up. It seems pretty strange that having the play head move
would be enough to cause a garbage collection.
2) This doesn't sound like the issue, but you may be having an issue
with scope chain and memory waste in Flash. One of the easiest ways to
leak tons of memory is to say:
function myFunction()
{
var x = new XML();
x.onLoad = new function() { // yada yada };
x.load ( myURL );
}
Instead, you want to say
function myFunction();
{
var x = new XML();
x.handler = this;
x.onLoad = this.xmlOnLoad;
x.load( myURL );
}
// this is the xml object here
function xmlOnLoad( success:Boolean )
{
var x = this;
// invole the real object
x.handler.onXMLLoadHandler( this );
}
This can cause huge amounts of waste (as it happened to me once). This
is explained in good detail here:
<http://timotheegroleau.com/Flash/articles/scope_chain.htm>
Good Luck!
I imagine my tests where actually a bit crap. In the actual app (which
doesn't even use the stage - trying to move over to MTASC :) ), calls
would be more like...
var stub = new RemoteStub();
stub.call("someMethod", params, callback);
Where the callback was a generated Proxy function. I dont suppose
Proxy's cause memory leaks do they? And then why would flash 8 solve
this problem?
-DW
Nick Griffiths wrote:
I know this should be on one of the as coders forums, but i thought
people here would be more able to answer this one.
We've stopped developing on the timeline, and our app seems to use
huge amounts of memory when left running for a long time. I thought
i'd narrowed it down to XML parsing (server polling), so I set up a
couple of tests; one which sits on a single frame of a movie clip
firing of server requests in a for loop, the other which fires of
requests every frame. The first test seems to use a huge amount of
memory that is never freed after (50 or so calls worth), while the
second cleans up every call and never goes over about 20mb.
I set up another test, a sort of mix between the two which did about
50 requests in a for loop, then moved along about 5 frames and a
key-frame. The swf in this one seemed to garbage collect after the
for loop when leaving the frame which had the code on it?
So what I'd like to know is, has anyone else had any problems with
flash not garbage collecting as you'd imagine? I've read somewhere
that it is done every minute, but that sounds pretty arbitrary. I'm
reasonably confident I'm not causing the memory leak, but then I
don't know enough about the Flash VM to be certain about that (I once
ready a spooky article about flash scoping, esp nested functions).
I await your comments with baited breath :)
Nick
_______________________________________________
osflash mailing list
[email protected]
http://osflash.org/mailman/listinfo/osflash_osflash.org
Kelvin Luck wrote: Are you trying to sending multiple requests to a
server within one frame? This seems kind of crazy anyway - what
information on the server is changing within a fraction of a second?
It sounds like you want to be using an interval (see setInterval) or
an onEnterFrame event to trigger your requests to the server. I'm not
surprised that requesting multiple XML documents within a frame
confuses the Flash Player and keeps it so busy it can't garbage
collect. If you want real time updated data from a server then you
should look into XMLSocket's and a socket server which could push the
new data as it changed...
No, I was just doing this to test when flash performed garbage
collection. I noticed that if you kept nullifying or replacing the
reference to the XML object in the loop, it wouldn't clear up the old
memory until the play head moved on, after the loop. My code was
something like this
<code>
var xml:XML = new XML("<remote method request/>");
for (var a:Number = 0; a < 50; a++) {
var rXML:XML = new XML();
rXML.onLoad = function() {
trace ("loaded yo");
}
xml.sendAndLoad("http://someUrl";, rXML);
}
</code>
This would run to completion, but flash would never return memory back
to OS, unless you added a line at the end, saying
gotoAndPlay("someFrameWithoutThisCodeOnIt").
You would have thought the space used by each rXML would have been
marked for collection once the reference was replaced (no references
where left, unless the onLoad was causing trouble), or am i missing
something?
I'm sorry I couldn't find a conclusive reason about all this, but
overall it seems like I was doing something with callbacks that flash 7
didn't like.
_______________________________________________
osflash mailing list
[email protected]
http://osflash.org/mailman/listinfo/osflash_osflash.org
