Starting reflection + data binding support in incubator?

[Henri Karapuu]

I just joined the list, so sorry if the subject has been beaten to
death (though, i did try to search..).

During the last couple of months i'v run into 8 different
implementations of reflection / bean introspection, and equally many
data binding implementations.

It's probably clear to everybody that this leads to a lot of wasted
effort, and more severely, will in future cause problems when the
frameworks, applications and widgets using the various incompatible
implementations need to play with each other.

Based on the above reasons, i would like to suggest starting an effort
in the Incubator project with the ultimate goal of bringing (partial,
generator based) reflection and (property based / NOT 'data aware
widgets') data binding to the main GWT project.

If this is accaptable, i'd volunteer to (i) contact all of the
currently known creators of reflection/binding implementations and try
to bring them together to participate, (ii) write design document on
this, (iii) based on design docs' feedback provide fully documented/
tested implementation, and (iv) see it through for the first couple
months for all bug fixes and possible design changes.

How about, are the partial generator based reflection support and
simple data binding features possible / wanted features for the main
GWT project? Meaning, green light or red light?

Regards,

Henri Karapuu

[Ray Cromwell]

Are you proposing to do this all at runtime? I would suggest that
bindings be done at compile time as much as possible. Most of the use
cases for runtime 'reflection' IMHO turn out to be because the
developers aren't using deferred binding techniques as much as they
should.

-Ray

[Henri Karapuu]

> Are you proposing to do this all at runtime?

I'm primarily proposing that this stuff 'should be done', because all
these different implementations are going cause significant problems
in future, and i'm totally open to all alternative ways of 'getting it
done' :)

> I would suggest that bindings be done at compile time as much as possible.

Could you elaborate on this? I do not really see how bindings could be
done at compile time (reflection sure, but bindings...?)

Here is a rough outline of the design we are currently using:

- Information about constructors, properties and methods of 'some
classes' are recorded at compile time, and can be queried through a
generic metadata facility.

- Three utility classes, which respectively allow for dynamically/
parametrically creating new instances, invoking their methods, and
getting/setting property values, are created at compile time for 'some
classes'.

- The 'some classes' mentioned above includes Widgets, classes
implementing certain marker interfaces, and classes added explicitly
to config file (for 3rd party stuff you cannot modify).

- Bindings operate internally only with an interface that we call
simply 'Bean' -- it has four methods, two for getting/setting property
values, and two for adding/removing property change listeners. You can
implement the Bean interface manually in your classes, or if you feed
plain widget or pojo to Binding, the Binding will internally wrap the
given widget/pojo inside an object that will use the generated utility
classes for translating parametric calls to the Bean interface to
actual method calls in the wrapped object (i.e.
setPropertyValue("firstName",someName) of Bean interface invokes
setFirstName(someName) in the wrapped pojo).

But, as i mentioned, this is only one view of how things can be done,
and i'm primarily interested in seeing common solution for this need,
instead of pushing our exact code, or my ego ... :)

Regards,

Henri Karapuu

[Miguel Ping]

+1, Looking forward to this! Databinding is an area where I guess that
gwt is somewhat lacking...

On Jan 22, 9:44 am, Henri Karapuu <hkara...@gmail.com> wrote:
> Could you elaborate on this? I do not really see how bindings could be
> done at compile time (reflection sure, but bindings...?)

I'm guessing that you are thinking of dynamically binded beans, like
binding the beans of the result of a RPC call to some table or so. I'm
also curious of what Ray said about 'compile time' binding.

[John Tamplin]

On Jan 22, 2008 4:44 AM, Henri Karapuu <hkar...@gmail.com> wrote:

- Three utility classes, which respectively allow for dynamically/
parametrically creating new instances, invoking their methods, and
getting/setting property values, are created at compile time for 'some
classes'.

The problem is once you allow for dynamically creating an object whose concrete class is only known at runtime, you would throw out most of the really cool optimizations the GWT compiler is able to do.  For example, no methods of the common superclass of these dynamically created objects down (ie, all classes if you allow Object as a superclass) can ever be inlined.  If you allow dynamic method invocation, you can never trim any unused methods on any of those classes.  If you allow dynamic field access you can never remove any unused fields.  A typical application will double (or more) in size and run much, much slower -- for example, just the inlining improvements in 1.5 alone, over what was already quite good in 1.4, has resulted in 200% speedup in real apps.  Such a change would be throwing out all of that improvement plus the related optimizations already present in 1.4.

I don't think that is an acceptable tradeoff, so I think these sorts of dynamic things will have to continue to be handled through code generation at compile time in a generator rather than some runtime reflection-like facility.

--
John A. Tamplin
Software Engineer, Google

[Henri Karapuu]

> The problem is once you allow for dynamically

...

> I think these sorts of
> dynamic things will have to continue to be handled through code generation
> at compile time in a generator rather than some runtime reflection-like
> facility.

Sorry John, i think i didn't explain my proposal well. Let's try
again :)

I'm fully aware of the consequences, and as i mentioned the reflection
support would be added only for classes marked explicitly with some
interface or in configuration file. Also, the reflection support can
be selective, i.e. certain class could get support for dynamic
property access, while other could get only dynamic instantiation.

For example to get data binding working for the typical use case only
dynamic property access is needed, and only for data transfer objects
and widgets. We have this system fully operational, and the measured
size increase of adding dynamic property access support for widgets is
only couple of kilobytes (it can be done against superclasses with
instanceof checks, so no widgets get forcibly compiled in).

Also, this proposal is indeed generator based approach: couple of
tool / utility classes are generated at compile time that allow the
limited explicitly configured reflection support. I'v checked the code
of about 6 out of 8 different reflection/binding implementations i'v
run into, and they all work more or less like ours.

To conclude:

- We have this working, and it's serving us well. And as 8 different
frameworks have independently created the same features with similar
implementations there probably is some point behind these ideas.

- However, i can understand very well if this kind of 'partially
working' feature is not acceptable as official addition to the main
GWT project. If this is how you feel, please just give me
confirmation, and we can consider the case closed?


Regards,

Henri Karapuu

[John Tamplin]

On Jan 22, 2008 12:22 PM, Henri Karapuu <hkar...@gmail.com> wrote:

- We have this working, and it's serving us well. And as 8 different
frameworks have independently created the same features with similar
implementations there probably is some point behind these ideas.

- However, i can understand very well if this kind of 'partially
working' feature is not acceptable as official addition to the main
GWT project. If this is how you feel, please just give me
confirmation, and we can consider the case closed?

I am only one member of the team so it isn't for me to decide anyway.  However, if you have it already working, the impact on code size and performance is minimized and only paid for if you use the feature, and it doesn't complicate other aspects of GWT I think it can certainly be considered for inclusion.

I am still rather skeptical that adding support for dynamic instantiation of objects and dynamic method calls has a small impact though -- I can see perhaps dynamic field access not having too large an impact since generally most fields do get used, but the others would seem to have too large a cost to pay.

Can you elaborate more on examples where you use this feature and the impact of those uses?  For example, a small snippet of code and the generated JS with -style PRETTY.

[Henri Karapuu]

> I am still rather skeptical that adding support for dynamic instantiation of
> objects and dynamic method calls has a small impact though

You don't have to be skeptical, it works exactly as you described
27.5cm above this line, in the first email to me :) If you add full
reflection support to everything, it's gonna bloat the code size
massively.

There are two keys why this works in practice:

- Careful, explicit selection of what parts of reflection to support
and for which classes. For example, adding dynamic instantiation
support for all widgets would force them all to get compiled in so
it's not very hot idea, but adding dynamic property access for core
widget properties such as text and visibility only requires couple of
kilobytes for all widgets.

- Secondly, this is mainly used in application (as opposed to
framework) level; controllers, views, data transfer objects and such.
For example in most projects it is safe to assume that the final
shipping version uses anyway every domain model class, and thus making
those dynamically instantiable does not increase code size expect for
the the generated 'tool' class (which is maybe 10 bytes per
instantiable class).

> Can you elaborate more on examples where you use this feature and the impact
> of those uses? For example, a small snippet of code and the generated JS
> with -style PRETTY.

Here are some important use cases:

- Data Binding:
// 2-way real time (every key press) binding between firstName
property of JPA entity and textBox
new Binding().from(myDomainObject,"firstName").to(textBox).andBack

- Generic Bean factory:
// Depending on configuration, scoping etc. may return a new instance
of FooView, or existing one
beanManager.getBean(FooView.class);

- Declarative UI with Lazy loading (XML can be loaded server on
demand):
<!-- At XML parse time the 'commandButton' tag causes corresponding
widget to get dynamically instantiated. At run time, when the button
is clicked, the method referenced by the #{expression} is invoked -->
<m:commandButton text="Click me to save!"
action="#{crudController.save(currentUser)}"/>

But your request of attaching code is bit difficult, as these use
cases drill through the entire framework. If we go forward with this,
i might need to prepare some isolated samples for evaluation.

I hope anyway that this clarified the thing a bit.


Regards,

Henri Karapuu

[Ray Cromwell]

On Jan 22, 2008 11:56 AM, Henri Karapuu <hkar...@gmail.com> wrote:
> - Data Binding:
> // 2-way real time (every key press) binding between firstName
> property of JPA entity and textBox
> new Binding().from(myDomainObject,"firstName").to(textBox).andBack

This can be done at compile time with a Deferred Binding Generator,
and if parameterized GWT.create() calls with de-magicified syntax, it
could look roughly the same.

Non-magic syntax version

public interface MyBinding extends Binding {

/**
* @gwt.from firstName
* @gwt.to textValue
* @gwt.twoway
*/
public void bindFirstname(DomainObject do, Textbox tb);
}

MyBinding mb = GWT.create(MyBinding.class);
mb.bindFirstname(myDomainObject, textBox);

As a bonus, the Generator would check if the bound field exists at
compile time, and field synchronization would probably be optimized
down alot more than a fully dynamic dispatch.

With a more magic-syntax (see other thread on GWT.create() arguments)
you could come close to the Guice-like syntax above.

> - Generic Bean factory:
> // Depending on configuration, scoping etc. may return a new instance
> of FooView, or existing one
> beanManager.getBean(FooView.class);

Already handled by existing Deferred Binding mechanism as well. I
don't see why the getBean() method can't simply be GWT.create() if
you're passing in class literals as arguments.

> - Declarative UI with Lazy loading (XML can be loaded server on
> demand):

There is already an official declarative UI in development for GWT.

> <!-- At XML parse time the 'commandButton' tag causes corresponding
> widget to get dynamically instantiated. At run time, when the button
> is clicked, the method referenced by the #{expression} is invoked -->
> <m:commandButton text="Click me to save!"
> action="#{crudController.save(currentUser)}"/>

Perhaps I'm misunderstanding, but how does this fit into GWT? The code
you wrote looks like standard JSF code that executes on the server,
not the client. I really don't think we need EL in attributes on the
client. I would hesitate to try and bring JSF concepts into GWT. I
might be going overboard in saying this, but I think JSF is a bad
design, and that something like Wicket is a much more appropriate
model for GWT from a philosophical design standpoint. I think it is
a mistake to try and bring too many server-side design practices
(Spring, JSF, etc) which heavily depend on reflection and
interception, into GWT, which is very much concerned with compile time
reflection and interception.

Just my 2 cents,
-Ray

[John Tamplin]

On Jan 22, 2008 4:34 PM, Ray Cromwell <cromw...@gmail.com> wrote:

> - Declarative UI with Lazy loading (XML can be loaded server on
> demand):

There is already an official declarative UI in development for GWT.

But it results in compile-time code generation.  There are reasons to prefer that over dynamically loading UI definitions, but it is not exactly the same as lazily loading the UI.  I think the problem you will have is wiring up all the event handlers to something loaded dynamically will take more code than just having defined it in the first place where the compiler/generator can optimize it for you, so the only way this is a win is if you essentially define most of your UI on the server, which will compromise the interactiveness of your app.

[Ray Cromwell]

I agree. I think generating server-side scenegraphs which get
instantiated on the client dynamically is kind of a Web 1.5 approach,
halfway between where you want to be (UI baked into client, data from
server), and it may serve some purpose in terms of migrating from
existing J2EE apps, but I think in general, GWT best practices should
not advocate it too strongly. Suitable but more optimal alternatives
(e.g. Linker) may be available in the future for loading up granular
modules of UI complete with wired up functionality as well.

The XML approach seems to treat GWT as if it's a UI Widget library like Dojo.

-Ray

[Henri Karapuu]

> > new Binding().from(myDomainObject,"firstName").to(textBox).andBack
>
> This can be done at compile time with a Deferred Binding Generator,
> and if parameterized GWT.create() calls with de-magicified syntax, it
> could look roughly the same.

Ray, thanks for your reply, but i don't quite follow your approach.

In your example the 'MyBinding' interface seems to be specific to the
classes participating in this particular example? Let's assume a small
scale application, with say, 20 domain model classes, 5 properties per
class, and 20 different widgets. Could you explain how in your
approach one would make binding from any given domain model instance
to a widget?

Surely i cannot create 400 interfaces for this use in advance, nor is
it realistic to stop the current programming 'flow' and switch
creating a new interface every time there is a new type-to-type
combination needed??

Also, i cannot see how your approach would handle more complex cases,
such as wildcard, recursive or chained bindings, i.e.
new Binding().from(user,"company.ceo.address.zip).to(...), or new
Binding().from(user,"*");

Note: this is a genuine question, i honestly don't understand your
proposal.

> Already handled by existing Deferred Binding mechanism as well. I
> don't see why the getBean() method can't simply be GWT.create() if
> you're passing in class literals as arguments.

You are right in the case of this example (it was badly chosen example
from my part). The idea was that the generic bean factory thingy can
instantiate things parametrically, i.e. you can feed it argument of
type Class, not only Class literal, or feed it string, or add new
types to the factory at run time.

> > - Declarative UI with Lazy loading (XML can be loaded server on
> > demand):
>
> There is already an official declarative UI in development for GWT.

Which does not support lazy loading, nor expressions. Also, i have not
been able to found any source code for it?

> > <m:commandButton text="Click me to save!"
> > action="#{crudController.save(currentUser)}"/>
>
> Perhaps I'm misunderstanding, but how does this fit into GWT? The code
> you wrote looks like standard JSF code that executes on the server,
> not the client.

It looks like standard JSF for a very good reason -- re-using JSF's
syntax gives full tool support from half a dozen different IDEs. For
example, with IntelliJ the method names referenced in XML get renamed
when the method is renamed, or you can jump to the method from XML.

Regards,

Henri Karapuu

[Henri Karapuu]

> I think the problem you will have is wiring up
> all the event handlers to something loaded dynamically will take more code
> than just having defined it in the first place where the compiler/generator
> can optimize it for you

Nope, wiring button clicks etc. to methods happens at runtime when the
lazily loaded XML is parsed, using expressions
('#{fooController.foomethod}') in the XML and reflection support for
the actual invocation. Basically the only associated cost should be
adding reflection support to the target method which will get invoked
with button click, and thats only some tens of bytes per method. Well,
thats the theory anyway -- the expression language has not been
implemented yet :)

> which will compromise the interactiveness of your app.

Which is where predictive (aka speculative) loading comes to play ..

However, i agree that 2 out of 3 use cases that i gave require
significant other parts of our framework before being useful for
general public, and they were probably ill chosen.

But let's see ray's answer for the data binding use case before
hitting final nail in the proposal's coffin? That was anyway my
original and only use case, and either ray's idea was unusable, or
then i was just too dumb to comprehend it :)

Regards,

Henri Karapuu

[John Tamplin]

On Jan 22, 2008 6:47 PM, Henri Karapuu <hkar...@gmail.com> wrote:

Nope, wiring button clicks etc. to methods happens at runtime when the
lazily loaded XML is parsed, using expressions
('#{fooController.foomethod}') in the XML and reflection support for
the actual invocation. Basically the only associated cost should be
adding reflection support to the target method which will get invoked
with button click, and thats only some tens of bytes per method. Well,
thats the theory anyway -- the expression language has not been
implemented yet :)

And the associated cost of no longer being able to optimize/prune methods which can be called through reflection (and the transitive closure of any methods called by any methods callable by reflection).

I thought you said you had this implemented already and that it had minimal impact?  Here, it looks like you are saying this hasn't been done yet.

[Henri Karapuu]

> And the associated cost of no longer being able to optimize/prune methods
> which can be called through reflection (and the transitive closure of any
> methods called by any methods callable by reflection).

We have been through this several times; what you say is true, but
when reflection support is used in app level code and in explicitly
configured way the effects of 'forced in' compiling are very limited.

> I thought you said you had this implemented already and that it had minimal
> impact? Here, it looks like you are saying this hasn't been done yet.

I said we have implemented the reflection support.

Here we were talking about expression language for XML based
declarative UI. ("the expression language has not been implemented
yet")

These are two entirely different things, and the way how you
formulated your remark did not rub me in a way that causes pleasure.

......

Anyway, it's obvious that this proposal is not going to progress and i
consider the case closed.


Regards,

Henri Karapuu

[John Tamplin]

On Jan 22, 2008 7:42 PM, Henri Karapuu <hkar...@gmail.com> wrote:

We have been through this several times; what you say is true, but
when reflection support is used in app level code and in explicitly
configured way the effects of 'forced in' compiling are very limited.

The point is it isn't just the one class that is affected.  If it calls, for example, Object.toString(), the compiler can no longer make assumptions about the possible callers of toString() since it could be potentially called from anywhere.  Likewise for any other methods it calls and the methods they call, etc.
 

These are two entirely different things, and the way how you
formulated your remark did not rub me in a way that causes pleasure.

I'm sorry you feel that way, as no slight was intended.

The point is I would like to see an example of the generated code in the face of a runtime reflection-like capability that doesn't show a large impact in the size and performance of the app.  You said it was not readily feasible to provide such information, so I remain skeptical given what I know about the compiler's optimization capabilities.

 

Anyway, it's obvious that this proposal is not going to progress and i
consider the case closed.

Clearly GWT development has been focused on doing more things at compile time rather than runtime as we believe that serves our mission of improving the end user experience (possibly at the expense of developer effort).  If you are suggesting that we change that approach for your use case, you need to demonstrate that the benefit is worth the cost, whether that be from a huge benefit or a small cost.

[Henri Karapuu]

> The point is it isn't just the one class that is affected. If it calls, for
> example, Object.toString(), the compiler can no longer make assumptions
> about the possible callers of toString() since it could be potentially
> called from anywhere. Likewise for any other methods it calls and the
> methods they call, etc.

John, i think i haven't fully understood this part of your point
earlier (Sorry for being so damn dumb!)

The thing is, when i'v checked compiled JS (of 1.4.60) i haven't
noticed optimizations that would depend on knowing all possible
'invocation paths' of certain method. What kind of optimizations you
are talking about, exactly?

It would be top priority to clear this thoroughly, if you can spare
some more time. Not only for my sake, but as i'v mentioned at least
half a dozen other frameworks are using the same approach, and IIRC
one of them by some guys who are writing new GWT book -- it would be
somewhat unfortunate if a new GWT book would teach reflection approach
that reduces the performance to half!

> I'm sorry you feel that way, as no slight was intended.

Peace. I come always thin skinned when my grand ideas (=illusions?)
are being shot down all day long :)

> You said it was not readily
> feasible to provide such information, so I remain skeptical given what I
> know about the compiler's optimization capabilities.

The new reflection stuff is only in a one-half ready framework, so
it's nasty to make suitable test bed. But, i will start working on
this first thing tomorrow morning.

Thanks for your patience, and sorry that it took so long from me to
really grasp what you were saying about the optimization issue.

I'll get back as soon as i'v managed to separate the reflection stuff
to something that can be tested independently.

Regards,

Henri Karapuu

[John Tamplin]

On Jan 22, 2008 9:30 PM, Henri Karapuu <hkar...@gmail.com> wrote:

The thing is, when i'v checked compiled JS (of 1.4.60) i haven't
noticed optimizations that would depend on knowing all possible
'invocation paths' of certain method. What kind of optimizations you
are talking about, exactly?

I am not positive about which current optimizations were included in 1.4.60 and which have been added since then, so I don't know how much of this applies.

One thing the compiler does is remove polymorphism by type-tightening.  For example, say you have Animal with a method makeNoise(), and a bunch of subclasses with their own implementations.  If the compiler can prove that the only time Animal.makeNoise() is called it is being called on a Cat object, it can replace all polymorphic calls to Animal.makeNoise() with a static call to Cat.makeNoise(), which then means it can be inlined (and that can be inlined into the caller of the method calling makeNoise(), etc etc).  As a side effect, the data required to make the polymorphic call can be tossed as well if not needed elsewhere.  Finally, functions known not to be needed, such as Dog.makeNoise(), are removed from the output.

Now if we had reflection so you could call a method of Animal dynamically at runtime, the compiler can no longer assume that.  It has to assume that there might be a reflective call to Animal.makeNoise() on something other than a Cat instance.  Therefore, it has to keep Dog.makeNoise(), Cow.makeNoise() etc, and even in Cat.makeNoise() it can't assume it is actually a Cat object as it could be a subclass, which further limits the optimization that can be done inside that method such as inlining (and transitively everything it calls).  I believe it would be theoretically possible to split the method into a polymorphic version and a static version and replace the calls that could be determined with the static version, but I don't think the compiler can do that currently (Scott will likely correct me if I am wrong) and you would still be stuck with the bloat of duplicating the code and keeping the polymorphic dispatch infrastructure.
 

I'll get back as soon as i'v managed to separate the reflection stuff
to something that can be tested independently.

Great, I look forward to seeing your results.

[Henri Karapuu]

> I am not positive about which current optimizations were included in ...

Thanks for the excellent description of the optimizations. It will
take a bit of time for me to absorb all that, and i might need to come
back later and haunt you with questions :) I also think it would
benefit many users if you guys would document this in some
place.. ..even those who are not interested in the real low level
stuff could get grasp of the basic concepts, and keep them in mind
when designing.

> Great, I look forward to seeing your results.

Okey, i got bit more on this (couldn't wait until morning):

It seems your main concern is that the mere presence of the reflection
system makes entire software to execute at half speed or so. Luckily,
this part is easy to test. I switched to GWT 1.5 and I'v only had time
to do the very first (really bad) cut at this. The initial result is
that populating 1000x5 grid with string constants was just as fast
with reflection and binding systems on, as it was without. (it took
about 1600ms, of which about 1500 was spent on setText. This was with
firefox 2 on mac book pro C2D, measured with venkman, -style forgetten
happily to pretty, machine not booted in between etc. all possible
confounding factors, so we don't need to care about this much).

Basically at this point i'd like to get bit of input from you: what
kind of tests you would like me to run / what kind of situations
should induce the negative performance effects most likely?

...

OTOH the situation with measuring the size increased caused by
'optimizations that cannot be done because of reflection' seems more
and more difficult. Firstly, the reflection and binding subsystems are
so central to the framework that i cannot run them in isolation;
adding them includes so much other stuff that the result gets totally
confounded. and even if i could, i wouldn't still know what part of
the size increase is caused by the methods that get compiled in
because reflection and binding code itself uses them, versus what part
of the size increase is caused by 'optimizations that cannot be done
because of reflection'.

The size of the generated 'supporting' code is of course easy to
measure, but that seems to be pretty small, and not the central issue
here (last time when i checked the widget property support was under
3kb, even though the generated classes are pretty stupid and non-
optimized).

Anyways, if you give me bit of instructions what to test i'll run the
stuff and send you better results in the morning.


Thanks for your time,

Henri Karapuu

[Miguel Ping]

Hi all,

If I understand the concept correctly, the 'dynamic' part of the
reflection subsystem allows one to invoke some method whose name can
be defined only at runtime. I'm guessing there is some JSNI/js code to
make this (ie, to map property methods to accessors, etc). If this is
the only 'dynamic' part of the framework, and the rest is achieved
through generators, it should be quite reasonable that the output
should not increase dramatically because the jsni helper code to make
the 'reflection' dynamic is generated only for classes that are
instructed that way.
If the price to pay for this extra code is only a small fraction of
the total of an app, and If i have fine grained control of what I want
to be able to 'dynamically introspect' then I don't mind of paying the
price. In the end, I would like to demarcate an entire class or a set
of methods as 'introspectable' and generate a complete set of CRUD
screens for that class.

Please correct me if I got the details wrong, but if I got the basic
idea right I don't think this is true 'dynamic introspection/
reflection', it's more like 'selective introspection through js
facilities' :) Anyway, it could be immensely usefull.

On a small side note, I'm guessing that if closures are to be
introduced in Java7 and if gwt implements them, we will see some nice
frameworks appearing :)

[Henri Karapuu]

> Please correct me if I got the details wrong, but if I got the basic
> idea right I don't think this is true 'dynamic introspection/
> reflection', it's more like 'selective introspection through js
> facilities' :) Anyway, it could be immensely usefull.
> Please correct me if I got the details wrong, but if I got the basic
> idea right I don't think this is true 'dynamic introspection/
> reflection', it's more like 'selective introspection through js
> facilities' :) Anyway, it could be immensely usefull.

Hola Miguel. You got the functionality part right, but the
implementation does not use JSNI.

JSNI does not (afaik, somebody correct me if i'm wrong) help anything
with reflection, as you can use only literal references to java side
(probably for the same reasons why general reflection support is not
baked into the java side in the first place).

Also, while i'm the one who tries to push reflection support, i must
say that i don't see much reason for reflection support if you want to
create crud views - for that use case deferred bindings should work
just fine.

Regards,

Henri Karapuu

[Henri Karapuu]

Good morning John. I got more results.

In theory, you are right: i'v been able to verify that using the
reflection support causes 'indirect' changes to javascript (prevents
optimizations) and slows down performance.

In practice: the maximum performance hit that i'v been able to produce
thus far (with GWT 1.5) has been 2%. Only type of 'indirect' change
that i'v found has been that $clinit has not been optimized out. The
impact of this has been very modest, for example with reflection
support enabled the setWidget() of Grid runs 0.0036 milliseconds
slower.

I saved -style PRETTY javascripts and the profiler reports of this
test with/without reflection support. I can't seem to find way for
adding attachments through the google groups web interface, if you
want to check them just email me at: myfirstname @ mylastname dot com.

I'll continue my efforts to produce bigger performance hit. If you
have good ideas on this let me know and i'll try to run the stuff.

Regards,

Henri Karapuu

[John Tamplin]

On Jan 22, 2008 11:46 PM, Henri Karapuu <hkar...@gmail.com> wrote:

It seems your main concern is that the mere presence of the reflection
system makes entire software to execute at half speed or so. Luckily,
this part is easy to test. I switched to GWT 1.5 and I'v only had time
to do the very first (really bad) cut at this. The initial result is
that populating 1000x5 grid with string constants was just as fast
with reflection and binding systems on, as it was without. (it took
about 1600ms, of which about 1500 was spent on setText. This was with
firefox 2 on mac book pro C2D, measured with venkman, -style forgetten
happily to pretty, machine not booted in between etc. all possible
confounding factors, so we don't need to care about this much).

It sounds like possibly your DTOs are simple enough and not really tied into the rest of the system so the effects of losing optimizations doesn't spread much through the rest of the app.  If that is also the case for real-world apps, then it seems that the cost may be worth paying for, especially if they have to be specifically requested.
 

Basically at this point i'd like to get bit of input from you: what
kind of tests you would like me to run / what kind of situations
should induce the negative performance effects most likely?

I think I can comment better after seeing the test code you ran and what was geneated from it.

[Henri Karapuu]

> I think I can comment better after seeing the test code you ran and what was
> geneated from it.

John i got a zip ready for your, what's your email address?

[rahul]

Is it something that can be shared with the rest of us who are chasing
this thread with interest as well? ;-)

Cheers,
Rahul