flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: Flex 5 UIComponent - Behavior Pattern
Date Mon, 23 Jan 2012 19:52:16 GMT

On 1/23/12 10:31 AM, "Doug McCune" <doug@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.

View raw message