incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frédéric Thomas <>
Subject Re: Starting with the Whiteboard Code
Date Tue, 07 Feb 2012 02:22:26 GMT

Thanks to clarify that point, it's very important to know that in the actual 
state, the framework is un-unit-testable (mainly for UIComponent(s) I guess, 
is that the same for the all framework ?).

"It is coupled tightly with dozens of other objects"
I'm doing an experiment to loosely coupled UIComponent, I'll probably push 
today on github what I already done, It's just a staring point and just a 
small part of what should be done (that is to say : States, transitions, 
effects, automation, styling implemented as Behaviors).
(BTW, I'm looking for interested folks willing to spend time on this 

Alex Harui said he succeeded chopped UIComponent into over 20 pieces but the 
perfs were bad because of the intersticial cost of the calls, here are the 
pieces of the conversation :

"Further back in this thread I stated that the prototype was not faster
because of 'interstitial' costs: the cost of adding an additional function
call to get to the subobject that actually does the work.

I think you have to give up on something: backward-compatibility, keeping
certain high-bandwidth 'behaviors' baked in', memory footprint, in order to
get gains.

Or do something more clever like figuring out how to do post-process
optimization of the SWF that can set up tail-call optimizations and reduce
the interstitial cost."

>>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 
>>"this" object for the function owner (but maybe that's what makes it a
>Believe me, I was surprised to find this out as well.  Basically, it is
>because of an inefficient implementation in the VM.

>At minimum, it has to reference two things: the pointer to the 'this' 
>and the pointer to the name of the method, so I'm pretty sure it has to be
>at least 8 bytes, but when I asked about it a while back, they decided it
>couldn't be less than 32 bytes (yes, bytes not bits).  Apparently there is
>other stuff that needs to be tracked as well.

Personally, in the tests I did, I wasn't able to efficiently measure the 
perfs, at the moment, I plug the behaviors at instanciation time but it 
takes the simple to the double to instanciate, it's variable, do you know a 
good way to perform efficiently these kind of tests ?
Did you already tried to loosly coupled UIComponent ?

Alex stated as well that "Interfaces, modularity and DI are all good things" 
but using Interfaces is unacceptable because the performences loss :

"Also, the AVM is not like the JVM.  For various reasons, language features
are not necessarily implemented as you might expect.  An empty interface
takes up 250 bytes in the SWF and about 1K of memory at runtime and causes
an empty interface constructor to run at when first used.  So, pairing every
class in the framework with an interface will likely degrade performance

If I'm not wrong, you did some deep experiments in DI and AOP, what can you 
say about performences ? did you do measurements ? if yes, how ?

I would be really interested to see what you did about that.

(And once again, sorry for my english, trying to get better).

-----Message d'origine----- 
From: Michael A. Labriola
Sent: Tuesday, February 07, 2012 1:35 AM
Subject: RE: Starting with the Whiteboard Code

>> Writing unit tests for the framework is something that could be started 
>> now.  The framework code is out there.
>>Are the other ones logical tests? In other words: Would they need to be 
>>ported to a unit-test system?

Unfortunately, with a few exceptions, unit tests *cannot* be written for the 
Flex framework. It isn't something that can be started. Unit tests by 
definition involve the writing of a test for a single object isolated from 
all other objects, not dependent upon global state, that also means they 
can't be dependent upon things like the frame rate and enter frame events.

Looking at something like UIComponent, it references singletons and static 
classes (global state). It is coupled tightly with dozens of other objects. 
It relies upon the LayoutManager, which relies upon the frames, to function.

There is nothing about the current state of Flex that approaches being 
testable in units. That's why so many of us have been arguing for 
refactoring for so long. Since most of our code involves extending or 
referencing Flex classes, and in most cases there aren't interfaces for 
those implementations, our code becomes un-unit-testable by association.


Notice: This transmission is intended only for the use of the individual or 
entity to which it is addressed and may contain information that is 
privileged or confidential. Any dissemination, distribution or copying of 
this transmission by anyone other than the intended recipient is strictly 
prohibited. If you have received this transmission in error, please notify 
the sender immediately by e-mail or telephone and delete the original 
transmission. Thank you. 

View raw message