On 1/23/12 10:31 AM, "Doug McCune" <d...@dougmccune.com> wrote:
> Alex, first, thanks for that memory breakdown, very helpful.
>
>
>> The issue was not in the cost of the
>> allocations, it was in the cost of an additional function call to run the
>> actual work. Everything is now being proxied.
>
>
> What if when setting the composited piece you always stored a hard
> reference to all the functions, so something like this:
>
> private var setFocusFunction:Function;
> public function set focusBehavior(value:IFocusBehavior):void {
>
> this.setFocusFunction = value.setFocus; //where setFocus() is a function
>
> }
>
> and then when needing to set the focus, UIComponent calls
> this.setFocusFunction() instead of calling focusBehavior.setFocus()
>
> Since now the function is stored in UIComponent, does that get around the
> perf. problem of always calling a proxy like focusBehavior.setFocus()?
Actually, that makes it worse, espeically from a memory standpoint. Every
cached function reference is just making the allocation size of the
UIComponent larger and more inefficient. And, a function reference itself
is some 100 bytes or so because it is a closure, not a pointer into code.
I think the answer lies in selecting high-traffic sub-objects and caching
their references (or not making them sub-objects at all and baking in their
behaviors). As I keep saying, no one rule can be universally applied.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
