[flexcoders] Re: Runtime Memory Problems
I might agree with that, but in Firefox this is not an issue. Firefox releases memory on a regular basis while IE7 does not seem to release until I exceed the physical memory on the machine. BTW: I posted the wrong sizes in my original email. The images we are dealing with are 256Meg to 600Meg and the application will get up over 2.5Gig and then free up memory. I have 2Gig of physical ram in my machine. Mike --- In flexcoders@yahoogroups.com, Alex Harui [EMAIL PROTECTED] wrote: GC is opportunistic. This means it does not run all of the time. It tends to be triggered by allocating memory instead of freeing it, so watching an idle app will almost never result in GC. A good test is to cycle between two images 1000's of times and see if memory usage is unbounded. -Alex
RE: [flexcoders] Re: Runtime Memory Problems
I saw another email yesterday saying that there are some known bad behaviors with IE7 that are being investigated... From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of One Person Sent: Friday, March 16, 2007 10:26 AM To: flexcoders@yahoogroups.com Subject: [flexcoders] Re: Runtime Memory Problems I might agree with that, but in Firefox this is not an issue. Firefox releases memory on a regular basis while IE7 does not seem to release until I exceed the physical memory on the machine. BTW: I posted the wrong sizes in my original email. The images we are dealing with are 256Meg to 600Meg and the application will get up over 2.5Gig and then free up memory. I have 2Gig of physical ram in my machine. Mike --- In flexcoders@yahoogroups.com mailto:flexcoders%40yahoogroups.com , Alex Harui [EMAIL PROTECTED] wrote: GC is opportunistic. This means it does not run all of the time. It tends to be triggered by allocating memory instead of freeing it, so watching an idle app will almost never result in GC. A good test is to cycle between two images 1000's of times and see if memory usage is unbounded. -Alex
RE: [flexcoders] Re: Runtime Memory Problems
What I've heard about IE is that unfortunately even though the Player has released the memory it needs, IE often does not, so your system manager will show IE taking up lots more memory than the Player itself is using. If you check the flash.system.System.totalMemory property you'll see what the Player itself is actually using. Matt From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Alex Harui Sent: Friday, March 16, 2007 10:55 AM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Re: Runtime Memory Problems I saw another email yesterday saying that there are some known bad behaviors with IE7 that are being investigated... From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of One Person Sent: Friday, March 16, 2007 10:26 AM To: flexcoders@yahoogroups.com Subject: [flexcoders] Re: Runtime Memory Problems I might agree with that, but in Firefox this is not an issue. Firefox releases memory on a regular basis while IE7 does not seem to release until I exceed the physical memory on the machine. BTW: I posted the wrong sizes in my original email. The images we are dealing with are 256Meg to 600Meg and the application will get up over 2.5Gig and then free up memory. I have 2Gig of physical ram in my machine. Mike --- In flexcoders@yahoogroups.com mailto:flexcoders%40yahoogroups.com , Alex Harui [EMAIL PROTECTED] wrote: GC is opportunistic. This means it does not run all of the time. It tends to be triggered by allocating memory instead of freeing it, so watching an idle app will almost never result in GC. A good test is to cycle between two images 1000's of times and see if memory usage is unbounded. -Alex
[flexcoders] Re: Runtime Memory Problems
We have a known bug filed that there are some GC issues with IE 7. I
don't have any workarounds unfortunately, you can try a brute force GC
by doing something like this:
try
{
var lc1:LocalConnection = new LocalConnection();
var lc2:LocalConnection = new LocalConnection();
lc1.connect('name');
lc2.connect('name');
}
catch (e:Error) {}
Matt
--- In flexcoders@yahoogroups.com, One Person [EMAIL PROTECTED] wrote:
Description:
We are creating a web-app built with Flex 2.
This app uses some very large image files (From around 256K to over
600K)
We have an image viewer section of our Flex app that will allow the
user to move from one image to another.
I was noticing that with our app in IE7 that memory useage would
climb each time we grabbed a new image but even after letting it set
for several minutes the memory usage would not go down. It was acting
as if Garbage Collection was not getting called. So I added all kinds
of code to make sure that we were letting go of the previous images
to allow Garbage Collection to work.
After 3 days of trying to track down the problem I decided to create
a smaller Flex app that only used our image viewer control to limit
the number of variables in the problem. After a few hours I still
could not figure out the problem so I replace our image view with a
standard mx:Image tag. The problem still existed after doing this.
Having take our code out of the picutre I decided to compare results
in FireFox. FireFox would Garbage Collect fairly quickly and the
problem did not seem to exist using my test Flex app in FireFox.
From what I can tell, IE7 and Flash (version 9.0.28.0) do not seem to
work well at allowing Garbage Collection to work.
I have the same version of Flash installed in FireFox 2.0.0.2 and
there does not seem to be any problem there.
The code below is what I used in my mxml file. To test it you will
need to point to some kind of large images that you have access to.
The images that I was using are on an internal network and so are
unavailable to anyone on the outside.
?xml version=1.0 encoding=utf-8?
mx:Application
layout=absolute
xmlns:mx=http://www.adobe.com/2006/mxml;
initialize=init()
mx:Script
![CDATA[
public var urls:Array = new Array();
public var index:int = 0;
[Bindable] public var tempUrl:String;
private function init() : void
{
urls.push( http://10.7.2.8/07026/07026_00115.jpg; );
urls.push( http://10.7.2.8/07026/07026_00116.jpg; );
urls.push( http://10.7.2.8/07026/07026_00117.jpg; );
urls.push( http://10.7.2.8/07026/07026_00118.jpg; );
urls.push( http://10.7.2.8/07026/07026_00119.jpg; );
urls.push( http://10.7.2.8/07751/07751_00473.jpg; );
urls.push( http://10.7.2.8/07751/07751_00474.jpg; );
urls.push( http://10.7.2.8/07751/07751_00475.jpg; );
urls.push( http://10.7.2.8/07751/07751_00476.jpg; );
urls.push( http://10.7.2.8/07751/07751_00477.jpg; );
urls.push( http://10.7.2.8/07751/07751_00478.jpg; );
urls.push( http://10.7.2.8/07751/07751_00479.jpg; );
urls.push( http://10.7.2.8/42401/42401_.JPG; );
urls.push( http://10.7.2.8/42401/42401_0002.JPG; );
urls.push( http://10.7.2.8/42401/42401_0003.JPG; );
urls.push( http://10.7.2.8/42401/42401_0004.JPG; );
urls.push( http://10.7.2.8/42401/42401_0005.JPG; );
urls.push( http://10.7.2.8/42401/42401_0006.JPG; );
urls.push( http://10.7.2.8/42401/42401_0007.JPG; );
urls.push( http://10.7.2.8/42401/42401_0008.JPG; );
index = 0;
setCurrentIndex();
}
private function setCurrentIndex() : void
{
img.source = urls[index];
}
private function previous_Click() : void
{
if( --index 0 )
{
index = urls.length-1;
}
setCurrentIndex();
}
private function next_Click() : void
{
if( ++index = urls.length )
{
index = 0;
}
setCurrentIndex();
}
]]
/mx:Script
mx:Grid width=100% height=100%
mx:GridRow width=100% height=30
mx:GridItem width=100% height=100%
mx:Button label=lt; click=previous_Click()/
mx:Button label=gt; click=next_Click()/
/mx:GridItem
/mx:GridRow
mx:GridRow width=100% height=100%
mx:GridItem width=100% height=100%
mx:Image id=img source={tempUrl} width=100%
height=100%/
/mx:GridItem
/mx:GridRow
/mx:Grid
/mx:Application
