It would be great if it was a blank slate without backwards compatibility worries. I for one don't mind just using 4.6 and fixing bugs but for a new project I could see many people being happy upgrading to a fresh new framework where lessons from the past few years have been applied without the bloat etc.
We already monkey patch stuff that we find due to the fact that we can't really sit and wait. I guess this doesn't work for everyone but at the same time I don't see how just maintaining the old SDK and fixing bugs could harm anything either while all the effort is put into a faster leaner framework. Wael On 23/01/2012 18:22, "Alex Harui" <aha...@adobe.com> wrote: > > > >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 >
