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.
>
>
>
>
>
>
> 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+unsubscr...@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.
