Performance GWT-RPC, JavaScript Overlays, RequestFactory etc.

[Elizabeth Lemon]

Hello everyone,
I have been looking around for a really long time now on these client-
server communication strategies and have had a difficult time choosing
the right approach for my application. It also doesn't help that I
don't have a very strong background on server sided coding :P

In any case, I am trying to find the approach that would give the best
performance on the client-side.

I know that GWT-RPC uses it's own protocol to get you to the server
side. It is built on top of RequestBuilder and converts your data
into a content-type of (what I read was) text/plain. From here, it
will reconstruct your java object onto the servlet.

JavaScript Overlays says that it has no overhead.

RequestFactory is supposed to be even faster than GWT-RPC. No
serialization is required, but apparently deserialization is.

Upon these, there is the old RequestBuilder with a JSONParser.

I want to minimize the amount of time it takes for the client to
deserialize it's data with a balance of data size.

My objects aren't too deep. At most, an object would contain a couple
of strings, and two arraylists of 100 objects than contain a couple of
other strings.

But if I can avoid the deserialization part (where I believe most of
the response time is being consumed by) by a simple eval on a JSON or
something, that would be great.

Other notes: I have flexibility in what server I can use. However,
eventually I would like to make web services for non-gwt platforms,
though I feel like I could reuse the same business logic and use a
different entry point to the service.
QUESTIONS:
1. What does it mean for JavaScript Overlays to have no overhead?
2. Which one would you say is fastest in terms of client side
performance?
3. What does it mean that JavaScriptObjects are Opaque?
4. Since JavaScript Overlays describe us extending JavaScriptObjects,
does that mean converting it to a JSON requires less (or even zero)
time than would GWT-RPC?

Thank you so much for your input~

[Thomas Broyer]

JSOs are a way of coding in Java against JavaScript objects. The JSO class is a shim that get totally compiled out: no overhead, no wrapping of the JS object.

> 2. Which one would you say is fastest in terms of client side
> performance?

Most probably JSOs, with JsonUtils for parsing.
Next I'd say AutoBeans, then RF, then RPC.
Note that server side performance is different: the rpc protocol is much simpler than RF, so it's faster.

> 3. What does it mean that JavaScriptObjects are Opaque?

Where did you read that?!

> 4. Since JavaScript Overlays describe us extending JavaScriptObjects,
> does that mean converting it to a JSON requires less (or even zero)
> time than would GWT-RPC?

Yes.
Most browsers can do JSON.stringify(), for others you'd have to use JSONObject.toString(), which has a small overhead.

>
> Thank you so much for your input~

Choose what works best for you (in terms of protocol), not necessarily the fastest. These won't be the bottleneck of your app's performance, DOM is much more of an issue (and of course the network and the server)

[Elizabeth Lemon]

Thanks so much for replying!

I read that JavaScriptObjects are an opaque handle in the javadoc
http://google-web-toolkit.googlecode.com/svn/javadoc/1.6/com/google/gwt/core/client/JavaScriptObject.html

When you mentioned how server side performance is different, is it
because of the protocol used to marshall and unmarshall the data once
it arrives on the server?

You mentioned that the DOM is much more of an issue? In what sense?
And how does one go about optimizing for this?

I always believed that gwt's deserialization via gwtrpc back into the
client side was the bottleneck. Which is why I began to consider
other options such as JavaScript Overlay Types. But then again, I
guess forgot that I would have to manage the JSON (or turn them into
POJOs, the advantage of GWTRPC you were speaking of I assume?) on the
server as well. I suppose the plus side to this is that there is very
little deserialization that is needed to be done on the client side.

Would I be correct in saying that, since I can't change the speed of
my client's computer, I should place the deserialization/serialization
work on the server (which I could always allocate more resources for?

I guess really I'm looking for bottlenecks or an architecture that
would give great scalability~

[Thomas Broyer]

On Thursday, March 15, 2012 1:33:31 AM UTC+1, Elizabeth Lemon wrote:

Thanks so much for replying!

I read that JavaScriptObjects are an opaque handle in the javadoc
http://google-web-toolkit.googlecode.com/svn/javadoc/1.6/com/google/gwt/core/client/JavaScriptObject.html

You might want to read the latest javadoc: http://google-web-toolkit.googlecode.com/svn/javadoc/latest/index.html

(it hasn't changed for JavaScriptObject since GWT 1.6, but still).

What the javadoc is trying to express is that a JSO is not a classical Java object, it's just, as I said earlier, a "shim" that allows you to access a JS object from your Java code.

It might also be a legacy of the times where you couldn't/shouldn't extend JSO (GWT 1.5 and earlier, "overlay types" were not officially supported at that time).

 

When you mentioned how server side performance is different, is it
because of the protocol used to marshall and unmarshall the data once
it arrives on the server?

Partly this, partly the semantics of the protocol. RequestFactory does more than simply calling methods remotely.

 

You mentioned that the DOM is much more of an issue? In what sense?
And how does one go about optimizing for this?

See http://www.google.com/events/io/2010/sessions/architecting-performance-gwt.html and various other Google I/O sessions.

I always believed that gwt's deserialization via gwtrpc back into the
client side was the bottleneck.  Which is why I began to consider
other options such as JavaScript Overlay Types.  But then again, I
guess forgot that I would have to manage the JSON (or turn them into
POJOs, the advantage of GWTRPC you were speaking of I assume?)

Did I ever said anything about an advantage of GWT-RPC over something else? ;-)

 

on the
server as well.  I suppose the plus side to this is that there is very
little deserialization that is needed to be done on the client side.

Would I be correct in saying that, since I can't change the speed of
my client's computer, I should place the deserialization/serialization
work on the server (which I could always allocate more resources for?

I guess really I'm looking for bottlenecks or an architecture that
would give great scalability~

You probably know the common wisdom about "premature optimization"?

Don't try to solve a problem you don't have (yet?).

FYI, Google Groups uses GWT-RPC.