Re: runAsync + permutations

I'm not sure I've seen this done before, but in theory what you are attempting should be supported? The CodeSplitter runs on each individual permutation, taking both java/js programs as input, and appears to have checks to confirm that only reachable code for that permutation ends up in the split points. This is well after the optimization loop too, so the each java program should have dead code removed from it after constants (like system.getProperty("foo").equals("bar")) have been handled (getProperty("foo") replaced with a JPermutationDependentValue early in the build, then in the specific permutation the real value is swapped in by ResolvePermutationDependentValues, then DeadCodeElimination first rewrites the "literal".equals("literal") to true or false and the entire if statement gets replaced with an empty statement by Simplifier, also in DeadCodeElimination).

Can you confirm how you are checking this? You said "the code splits are generated all the same" - does that mean that the same number of split points exist and have should-be-pruned code in them, or that they exist but are actually empty (or mostly empty, minimum size is a under 1kb iirc)? Also, is there any chance that you've told the compiler to not heavily optimize? This is a long shot since even one pass through the optimization loop should make these changes, but is my next best guess just from reading the code briefly.

It does appear that the "count how many split points exist at all" (aka ReplaceRunAsyncs) happens before permutations are considered, so my hunch would be that those garbage split points are actually small or empty, and that avoiding generating them at all would probably be more trouble than it is worth, but I'm not certain about this.

On Friday, June 26, 2020 at 7:31:12 AM UTC-5 Alexander Bertram wrote:

Hi there,

I've have defined a second set of permutations for our app based on screen size. When screen size dips below 768, the property "form.factor" is set to "mini", and we bind the entry point to a different implementation.

<replace-with class="com.acme.ui.client.MiniEntryPoint">
<when-type-is class="com.acme.ui.client.LargeEntryPoint" />
<when-property-is name="form.factor" value="mini"/>
</replace-with>

The LargeEntryPoint contains many more features, and uses GWT.runAsync() to split some of the larger ones from the initial download.

The mini permutations correctly only include the features included from MiniEntryPoint. BUT they also include identical splits for each of the GWT.runAsync() calls, even though the GWT.runAsync() calls are not reachable from MiniEntryPoint.

I've even tried wrapping the calls to GWT.runAsync() in:

if(System.getProperty("form.factor").equals("full")) {
   GWT.runAsync(new RunAsyncCallback() {
      // ...
   });
}

but it has no impact - the code splits are generated all the same.

This isn't a show stopper as these split points are ever loaded from the mini app, but it would be nice to reduce the extra compile and deploy time involved in these large split points.

Is it possible that the code splitting runs before dead code elimination in each permutation? Any workarounds?

Thanks,

Alex

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/acb5f188-6555-4831-b3e5-00257adeaa27n%40googlegroups.com.