Size of output is little large

[Kirill Prazdnikov]

Hi,

I have a simple GWT program:
https://gist.github.com/kirillp/c443966b28ca68cd21e51ff802fde97d

And it compiles and run.
However, in single permutation "safari" and SSO linker it produce about 1100 lines of (auto-formatted) code including
user agent parser, adds a window listener, e.t.c

How can I reduce things I don't need ?

Thanks

[Colin Alworth]

Without actually compiling the code (see my final paragraph...), you
might not even need the safari permutation, but might get by with no
UserAgent wiring at all. You could experiment with your inherits
statements, and see if you can remove User, and only depend on
com.google.gwt.core.Core from the main portion of GWT itself. This at
least will remove the user agent parser (which is there to confirm that
you aren't accidentally running the safari permutation in IE, for
example). Alternatively, you can disable that runtime check:

   <set-configuration-property name="user.agent.runtimeWarning"
   value="true"/>

If you go this route, also consider disabling the document mode check,
another piece of GWT sanity check that happens on startup:

  <set-configuration-property name="document.compatMode.severity"
  value="IGNORE" />

--

Your code looks like it might be a stripped down version of something
more interesting that you will write later, but if it turns out that you
will be keeping it that simple, consider turning off stack trace
emulation. It doesn't actually _entirely_ remove the stack trace
collection code (I'm actually already looking into how to fix this), but
it does minimize what is needed for your app to turn on. The three
values are native, emulated, and strip: native assumes that browser
provides some ways to read the stack already, emulated bakes in a ton of
extra debug information into your compiled sources, and both of them
review and attach that information to java Exceptions. Strip, on the
other hand, does nothing except fill the collector-shaped hole so that
the rest of GWT believes everything is working correctly:

  <set-property name="compiler.stackMode" value="strip" />

--

Much of what remains is various Java emulation for types (including some
which are incorrectly not pruned, like ClassCastException in an app
which can't throw such an exception). There isn't a lot in 2.8 that can
be done to remove that code, but for any code more interesting than
creating a single object and attaching it to the window it will be
required to behave like proper Java.

--

After compiling a trivial GWT app (native window.alert from entrypoint)
I don't get any code adding a window listener. I also am not seeing
JsGlobals.getWindow() anywhere in either 2.8 elemental nor
elemental2-experimental 16-06-30. Where is that coming from, and is
there any chance that it has static setup code that wires up the
listener?

[Kirill Prazdnikov]

Hello,

Thanks for the explanation, 

<set-configuration-property name="user.agent.runtimeWarning" value="false"/>

did the job, and removed "$wnd.setTimeout($entry(assertCompileTimeUserAgent));" at the entry point. 

But document.compatMode.severity=IGNORE did not change anything in code generation, it still generates

severity = ($clinit_DocumentModeAsserter$Severity() , IGNORE);
if (severity == IGNORE) {
return;
}

It is unclear for what reason GWT generates (and never uses in the generated code):

if (!$wnd_0.__gwt_stylesLoaded) {
  $wnd_0.__gwt_stylesLoaded = {};
}
if (!$wnd_0.__gwt_scriptsLoaded) {
  $wnd_0.__gwt_scriptsLoaded = {};
}

It also would be very nice to remove that:

 

function isHostedMode() {...} if (isHostedMode()) { alert(...); }

And I see a lot of never used variables in the generated code, ex:

var Lcom_google_gwt_core_client_impl_SchedulerImpl_2_classLit = createForClass(22);
var onBodyDoneTimerId = setInterval(function () { ....
var $gwt_version = "2.8.0";
var $stats = $wnd.__gwtStatsEvent ? function (a) { ....
var $strongName = '6D7BE6648CA01BEDC1B199CE04D6BBCD';
var Lcom_google_gwt_core_client_impl_StackTraceCreator$Collector_2_classLit = createForClass(37);
var Lcom_google_gwt_core_client_impl_StackTraceCreator$CollectorLegacy_2_classLit = createForClass(18);
var Lcom_google_gwt_core_client_impl_StackTraceCreator$CollectorModern_2_classLit = createForClass(19);

Is it an issue that the GWT generates never-used variables ? 

Thanks

[Colin Alworth]

Class literals for any object which can be created need to exist for getClass(), which is called by toString() at the very least - if the compiler sees any Object.toString, it must leave in all getClass methods - further reasoning about that might be tricky, and is a little out of my wheelhouse. If memory serves, class literals are harder to prune since they can be used in split points (though the class literals must exist in the original split point). 

The vars __gwt_stylesLoaded and __get_scriptsLoaded are part of the linker's communication with the main page, and how the linker defines what other resources it has grabbed up from the .gwt.xml file. $stats serves a similar purpose, it is one of several ways for the page to communicate with the module and vice versa. A custom linker can be written by forking one of the existing ones to remove these or simplify them if you never will have a use for them and really must save a dozen or so bytes each. Since there are a fixed set of these, it is a constant overhead, and won't grow as your application grows. These can't be optimized out without knowing how you will end up using the GWT app from the host page, which by definition isn't compiled as part of the app.

I *believe* that the useless if statement you showed will be optimized out if you avoid PRETTY and do a normal compile, but I am not totally certain - clinits do seem to interfere with some optimizations of dead code. I'm looking into a way to deal with some of these cases, will post back within a few weeks if I am successful (and have time). As before though, simply depending on Core instead of User will avoid this entirely.

If you are really after saving individual bytes, especially if you only have a single permutation, do look at building your own linker, and depending only on Core directly (and skipping the UserAgent module), and possibly rebinding some of these generated classes to do nothing.

[Ray Cromwell]

FYI: https://plus.google.com/+RayCromwell/posts/VK8URgZiLbS

> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-co...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/19737425-edc4-47c7-8eab-e78d070f7c51%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

[Kirill Prazdnikov]

That sounds very good, can you share the source ? 

The 3) and 4) is most interesting.

Thanks

 Ray Cromwell:

FYI: https://plus.google.com/+RayCromwell/posts/VK8URgZiLbS