RequestContext Overhead

[John Maitland]

Is there a overhead to having multiple RequestContexts inside a
RequestFactory? I know with RPC, there was a overhead of having
multiple async services.

John

[Thomas Broyer]

Each RequestContext will have an implementing class generated, so yes, there's an overhead (class metadata, initialization code, etc.)

The overhead is much lower as with RPC though (as much more code is shared between contexts than between RPC services).

Just a reminder though: premature optimization is the root of all evil (http://en.wikipedia.org/wiki/Program_optimization#When_to_optimize)

...and the GWT compiler improves from version to version so that the overhead becomes lower over time (so you don't even have to think about it, until you *have* to think about it (i.e. you have a perf issue, and you identified through benchmarks and other perf analysis that it's a bottleneck))

Compare that overhead with the reduced readability (thus less maintainable code) of a giant RequestContext, and particularly its server-side counter part service, with dozens of methods!

[Thomas Broyer]

[John Maitland]

Thanks Thomas. And the code sharing between request contexts is done
at the RequestFactory level or between request factories. For example,
if I have a entity proxy that is used on multiple request factories
would that be shared? This is important if you wanted to code split an
entire request factory compared to passing a reference from the
initial fragment (i.e. one giant request factory, lots of request
contexts vs lots of request factories with one contexts).

John

[Thomas Broyer]

On Tuesday, August 30, 2011 6:52:57 PM UTC+2, John Maitland wrote:

Thanks Thomas. And the code sharing between request contexts is done
at the RequestFactory level or between request factories. For example,
if I have a entity proxy that is used on multiple request factories
would that be shared?

As far as I can tell, the overhead is per-RequestContext: there's on AutoBeanFactory per RequestContext, plus one "giant" one per RequestFactory: http://code.google.com/p/google-web-toolkit/source/browse/trunk/user/src/com/google/web/bindery/requestfactory/gwt/rebind/RequestFactoryGenerator.java

 

This is important if you wanted to code split an
entire request factory compared to passing a reference from the
initial fragment (i.e. one giant request factory, lots of request
contexts vs lots of request factories with one contexts).

It should be easy to write a small app and use the compile report to validate those speculations. 

[John Maitland]

I agree that it looks like the overhead is per-requestcontext. This is
also reflected in the size of the abstract request factory vs the
abstract request context.