flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Taylor <ja...@dedoose.com>
Subject RE: massive memory leak in Flex
Date Mon, 06 Mar 2017 21:13:08 GMT
excellent, I'll just add this permantly in to our debug builds so our QA can check for mem
leaks as well. Ty.

Currently, I believe the issue is scout holding onto references and thus not allowing the
items to hit GC

-----Original Message-----
From: Alex Harui [mailto:aharui@adobe.com] 
Sent: Friday, March 03, 2017 2:35 PM
To: dev@flex.apache.org
Subject: Re: massive memory leak in Flex

On 3/3/17, 1:23 PM, "Jason Taylor" <jason@dedoose.com> wrote:

>sounds good, this is all stemming from a memory I discovered in our 
>SparkTree component which is based off 
>https://github.com/kachurovskiy/Spark-Tree which I'm sure a lot of 
>people use.  In the middle of redesigning a solid tree component based 
>of SaturnBoy's work that is FAR more performant with a lot less code 
>complexity, and hopefully dosen't exhibit the memory leak issue.

OK.  I'm not clear if you still think there is a memory issue or just saw some aliasing from
Scout.  The System.totalMemory technique is how we used to test for memory leaks before there
were FB Profiler and Scout and is less likely to cause aliasing.  I haven't used that technique
in a long time, but I think maybe I actually used code like:

Var tm:int = System.totalMemory;
Math.max(lastTotalMemory, tm)
lastTotalMemory = tm;

so you are observing the high water mark.


View raw message