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? Chris ________________________________________ Von: Marcus Wilkinson [[email protected]] Gesendet: Mittwoch, 16. Oktober 2013 12:00 An: [email protected] Betreff: Re: Sorting out Memory issues Chris, 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) { super(); ... _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. Marcus On 16 October 2013 09:26, [email protected] < [email protected]> 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 >
