Have you seen
http://www.google.com/events/io/2011/sessions/high-performance-gwt-best-practices-for-writing-smaller-faster-apps.html?
Also check out the performance-related sessions from previous years at I/O.

Your observations appear sound: if you add a widget with lots of
dependencies, you're going to see a significant bump in code size. It has
often been noted that RequestFactory is bigger than RPC in terms of initial
download; however, if you include a Command pattern implementation and the
extra classes required to use Command pattern with GWT RPC, I doubt it's
much different. And RequestFactory should give you smaller payloads than GWT
RPC because it sends only deltas and doesn't send the whole object graph by
default.

It sounds like you're taking the right approach. Try out different widgets /
features for your application and measure the resulting size (hopefully
you're using -compileReport to get additional size-related info?) Because
the GWT compiler does whole program optimization, this is the only way to
get results that are accurate for your app.

/dmc

On Sun, Jul 10, 2011 at 1:20 AM, Andrei <[email protected]>wrote:

> Concerns about the size of GWT complied code has been raised several
> times in this forum, but a typical response was "Relax, dude!" with
> slight variations like "It can be cached" and "Don't forget about
> gzip".  I am still concerned, though, that even the most simple GWT
> app easily tops 150kB in compile size.
>
> I started looking at the compile reports, and I noticed some
> interesting things.
>
> (1) I imported java.util.Comparator in one place in the app, and it
> immediately added a ton of Java classes to the compiled code,
> including Java.util.Date, java.lang.Float, java.lang.Double, and so
> on. I don't use this classes anywhere in the app, and the compile
> report traces them all to java.util.Comparator. I did not measure
> precisely, but I've got around a 10kB bump in the compiled app size
> after using comparator once (and I use it to compare String properties
> of two objects).
>
> (2) I don't use dates or time anywhere on the client side. I have one
> server-side method which uses dates by adding a timestamp to an
> Appengine Datastore. So I was very surprised to see
> java.sql.Timestamp, java.sql.Date, and java.sql.Time, in my compile
> report. These classes are not big, but why they were included? I don't
> send date or time over the wire (and I don't use sql), but I see them
> traced to
>
> com.google.gwt.user.client.rpc.core.java.sql.Time_CustomFieldSerializer::instantiate.
>
> (3) In my app many classes are traced exclusively to DockLayoutPanel,
> including java.util.AbstractHashMap, java.util.HashSet, and the like.
> Is there an assessment anywhere of how heavy each widget is in terms
> of its impact on the compile size? It's very hard to figure out as
> each widget has a different impact based on which other widgets are
> already present, and some widgets have no real alternative anyway
> (CellTable is very heavy, for example, but I have to use it
> regardless), but any tips/guidance would be appreciated.
>
> (4) I never used anything touch-related in the app, but
> com.google.gwt.touch.client is present in the compile report. All of
> its subclasses trace back to ScrollPanel. I guess it may be useful in
> some use cases, but I would like to have a way to turn it off when I
> offer a separate GWT file for mobile devices.
>
> (5) I replaced RPC calls with RequestFactory, and the compile size
> ballooned by 150kB (the app had only two RPC calls at that stage). The
> benefits of RequestFactory quickly paled in my eyes. Did I do
> something wrong, or other people had similar results?
>
> I understand that as the app gets bigger and bigger (and the Internet
> faster), these issues will be comparatively less and less important. I
> do have, however, customers with slower connections / in remote
> locations / on expensive mobile data plans, for whom initial download
> size matters. Not to mention extra bandwidth costs which grow in line
> with the number of customers (Isn't that the reason Gmail, YouTube,
> and Google+ are not written in GWT?).  I would be grateful if the
> experts on this forum share their tips on reducing the compile size of
> the app.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google Web Toolkit" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/google-web-toolkit?hl=en.
>
>


-- 
David Chandler
Developer Programs Engineer, GWT+GAE
w: http://code.google.com/
b: http://turbomanage.wordpress.com/
b: http://googlewebtoolkit.blogspot.com/
t: @googledevtools

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Reply via email to