incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Frishberg <fri...@gmail.com>
Subject Re: Flex 5 UIComponent - Behavior Pattern
Date Mon, 23 Jan 2012 20:05:36 GMT
> 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 understand that caching every function would be expensive, but I don't
understand why a reference to a function isn't just 4 bytes.  Why is it a
closure?  The only thing I can think of that would be in scope would be the
"this" object for the function owner (but maybe that's what makes it a
closure)?

-Ryan

On Mon, Jan 23, 2012 at 7:52 PM, Alex Harui <aharui@adobe.com> wrote:

>
>
>
> 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.
> http://blogs.adobe.com/aharui
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message