On 1/23/12 8:43 AM, "Doug McCune" <d...@dougmccune.com> wrote:
> Just one counter-thought to play devils advocate a bit. One thing you have
> to consider is performance, especially on something like UIComponent that
> drives every little thing in your app. And in general, creating lots of new
> Objects is slow (and disposing of them can also be slow due to the GC).
Actually, creating lots of small objects can be faster than creating a few
big objects. Yes, there is more work for the GC to do afterwards, but GC
rarely shows up in most profiles. This odd fact has to do with the way
memory is managed in the VM. Memory is allocated from the OS in 4K chunks.
A few bytes are reserved for GC management, then the rest is divided up into
a certain block size. There is a chunk for 16-byte allocations, a different
one for 24-byte allocations, etc, on up to 1K or so. The allocations are
factored out like this: Take 4096 bytes, remove something like 10 bytes for
GC administration, that leaves 3996 bytes. Divide that by 16, that results
in 249 allocatable 16-byte chunks on that 4K page with 12 bytes waste per
249 allocations. If you ask for 249 14-byte allocations, it gets allocated
from the 16-byte chunk, and you've wasted an additional 2 * 249 bytes. Out
at the size of UIComponent which is about 1000 bytes, we only get 2 or 3 per
4K page, not very efficient, and the allocator goes back to the OS quite
often. If you broke stuff down into lots of smaller allocations, the theory
says it actually goes back to the OS less often which not only saves cycles
but memory as well! In fact, a simple test shows this is true.
> Overall I think most people see the benefit of a highly-composited
> UIComponent that lets you define only the necessary functionality and lets
> you swap out each little bit of behavior with another. However, if you end
> up with all UIComponents creating 100 new objects each time a UIComponent
> is initialized, you may be trading a nice architecture for performance.
I actually spent 3 months on doing this very thing and the results was that
Helloworld was not faster. 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. And it turns out, for small
apps, there isn't enough stuff not being considered when you are trying to
be backward compatible to save enough to make this pay off.
An additional hurdle is that, to be backward compatible, you would want to
retain certain methods on UIComponent as protected. But as soon as you move
work out to a sub-object, you cannot call that protected method. There is
no "friend" concept in AS.
This thread is essentially a repeat of early threads on this list.
Everybody likes the idea of composition over inheritance. You have to watch
out for performance. Backward compatibility is difficult and expensive.
Flex is running in a constrained environment, no one rule applies
everywhere.
And that's why, on my whiteboard, if I ever get done with doing legal
clearance, I will start over, abandon backward compatibility, and use more
composition, and see what happens.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
