Ways to reduce GWT compiled code size
487 views
Skip to first unread message
Andrei
Jul 10, 2011, 1:20:38 AM7/10/11
to Google Web Toolkit
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.
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.
Andrei
Jul 10, 2011, 2:36:53 PM7/10/11
to Google Web Toolkit
I replaced DockLayoutPanel (I had only one) with LayoutPanel (I had a
few of them already). It reduced the size of the compiled code by
2.6kB. There were no other changes in the app.
Andrei
few of them already). It reduced the size of the compiled code by
2.6kB. There were no other changes in the app.
Andrei
Andrei
Jul 10, 2011, 3:23:27 PM7/10/11
to Google Web Toolkit
Another small data point. Adding a single reference to an empty
CellTable immediately increases the compiled size by 30kB. Column
sorting and Dataprovider add another 5kB.
CellTable immediately increases the compiled size by 30kB. Column
sorting and Dataprovider add another 5kB.
Olostan
Jul 10, 2011, 7:15:22 PM7/10/11
to google-we...@googlegroups.com
Hi
But what about code splitting? May be it can help you to reduce at least startup time of an app?
ofcourse, you've posted very srtange facts. I am very surpirised becaurse i've thought that GWT do optimization steps as long as it can optimize - normally compiling takes quite long time.
It would be really gteat if some GWT expers will comment if this is normal behavior of GWT...
Andrei
Jul 11, 2011, 4:02:45 AM7/11/11
to Google Web Toolkit
I have one app in which users may go entire sessions without accessing
some places (I use Places & Activities pattern), and in such cases
code-splitting helps a lot. I have another app, in which users are
expected to visit all places. In this case code-splitting helps to
reduce the initial load, but ultimately the entire compiled code has
to be loaded. It is not a big deal for desktop apps (assuming good
connection speeds), but I was planning to use GWT for mobile versions
of these apps, and the compiled size scares me. So far it looks to me
that GWT is not the right choice for a mobile app. I hope to be
convinced otherwise. A native app with the same functionality will be
many times smaller, but it's a lot of extra work to write a native app
for each mobile platform.
some places (I use Places & Activities pattern), and in such cases
code-splitting helps a lot. I have another app, in which users are
expected to visit all places. In this case code-splitting helps to
reduce the initial load, but ultimately the entire compiled code has
to be loaded. It is not a big deal for desktop apps (assuming good
connection speeds), but I was planning to use GWT for mobile versions
of these apps, and the compiled size scares me. So far it looks to me
that GWT is not the right choice for a mobile app. I hope to be
convinced otherwise. A native app with the same functionality will be
many times smaller, but it's a lot of extra work to write a native app
for each mobile platform.
Alain Ekambi
Jul 11, 2011, 7:18:13 AM7/11/11
to google-we...@googlegroups.com
Have you tried appcelerator ? http://www.appcelerator.com/
--
--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
--
GWT API for non Java based platforms
dreamer
Jul 11, 2011, 10:05:04 AM7/11/11
to Google Web Toolkit
Hi,
Couple of tricks in personal experience.
1) Use concrete classes instead of interfaces, especially in case of
collections, with interfaces compiler has to add all possible classes,
as it does not which class at run time.
2) avoid iterators, use for loop
3) when we are using widgets - nothing much to do, but inside info may
give little info, which is light weight, but reuse same widget in as
many places as possible
and avoid using all kinds of widgets, if no real reason.
Couple of tricks in personal experience.
1) Use concrete classes instead of interfaces, especially in case of
collections, with interfaces compiler has to add all possible classes,
as it does not which class at run time.
2) avoid iterators, use for loop
3) when we are using widgets - nothing much to do, but inside info may
give little info, which is light weight, but reuse same widget in as
many places as possible
and avoid using all kinds of widgets, if no real reason.
David Chandler
Jul 11, 2011, 10:44:57 AM7/11/11
to google-we...@googlegroups.com
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
--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Reply all
Reply to author
Forward
0 new messages