> 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 <aha...@adobe.com> wrote:
>
>
>
> 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
>
>
