flex-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "christofer.dutz@c-ware.de" <christofer.d...@c-ware.de>
Subject AW: Sorting out Memory issues
Date Thu, 17 Oct 2013 09:11:37 GMT
Hi Marcus,

yesterday I did a Little more investigating. I could find out that there was an insane amount
of Events generated the UUIDs of These seem to have consumed about 60MB. The reason for this
seems to be that I was using the Default GraniteDS Templates (With minor modifications to
make the model classes work with BlazeDS) in my flexmojos build to generate ActionScript model
classes from my Java classes. This build generated the model classes with [Bindable] on class
Level. I modified my templates to simply create non-bindable classes and the Event-Inferno
seems to have been resolved.

But I can confirm that the UUID Generation seems to cause a significant amount of CPU and
Memory usage. Eventually it would be good to address this on a Framework Level.

While investigating the "source" method of ArrayCollection (I could have beet that this was
implemented greatly different in Flex 3.x), I could see that internally the Array is wrapped
by an ArrayList and that there is an alternate implementation with the same Name form an Apache
Flex package which seems to work with vectors. What's actually the difference between the
two ArrayList implementations? Could it be beneficial to Switch to the new Apache implementation
officially in the ArrayCollection class?


Von: Marcus Wilkinson [wilkinsonmarcus@gmail.com]
Gesendet: Mittwoch, 16. Oktober 2013 12:00
An: users@flex.apache.org
Betreff: Re: Sorting out Memory issues


This may be unrelated, but we were having big performance problems during
deserialisation of many separate ArrayCollections. The biggest bottleneck
was in the constructor of ArrayCollection, which would use an ArrayList in
its backing collection. Inside that function there is code:
    public function ArrayList(source:Array = null)
        _uid = UIDUtil.createUID();

The UIDUtil.createUID was taking way too long and some of the memory didn't
seem to get freed in a timely manner.
We monkey patched ArrayList to return a quicker UID:

private static const ARRAY_LIST_UID_PREFIX:String = "_array_list_uid_";
 private static var _count:int = Number.MIN_VALUE;//int.MIN_VALUE;
 private static function getUID():String {
 return ARRAY_LIST_UID_PREFIX+String(_count++)+String(getTimer());

Probably not the cleanest way to do this but it runs much more quickly.
Thought it may help you or others in this situation. I haven't raised an
apache flex bug because it seemed pretty specific to our situation.


On 16 October 2013 09:26, christofer.dutz@c-ware.de <
christofer.dutz@c-ware.de> wrote:

> Hi,
> I am currently having Major Memory issues, which I haven't quite managed
> to sort out.
> In my application (Apache Flex 4.10 ... but wasn't any different in older
> and/or Adobe Versions) I am loading a list of objects and this list is
> updated via server-push (Streaming AMF Connection). For testing, I
> increased the amount of data sent back to the Client when loading the list.
> Currently about 12000 Objects are returned using about 107MB (according to
> Adobe Scout).
> The returned list of objects is displayed in a Flexicious Ultimate
> DataGrid (The Performance of this is very sattisfying considering the
> amount of data it has to handle).
> There is a Feature to force a reload of the list. As removing all elements
> of an ArrayList and then adding 12000 Objects caused Major Performance
> problems, I changed the code to replace the source array of the
> ArrayCollection and then to make the list update itself after that. Each
> time the list is reloaded 107MB are used but I can't see any Memory being
> freed.
> Is there something wrong with my Approach? Do I have to Keep something
> else in mind? Are there some hidden internals keeping a reference to my
> objects so they aren't cleaned up?
> Help greatly appreciated.
> Chris
View raw message