Wednesday, September 25, 2024

Re: Digest for google-web-toolkit@googlegroups.com - 2 updates in 1 topic

Just checked to be sure.
My previous project had 18M per permutation of cache.js, no split points and an -Xmx2000m for gwt compilation.
I just built the web project on my laptop and it was a 2 min build.
I don't know what one would have to do to require that many mem - or even need split points. I never ran into the need for more mem/split points.
But now I'm quite curious though ;-)

On Wed, Sep 25, 2024 at 10:56 PM <google-web-toolkit@googlegroups.com> wrote:
Jens <jens.nehlmeier@gmail.com>: Sep 25 02:40AM -0700

Are you using a lot of code split points? 61GB memory seems pretty high.
Someone else once posted a similar question and this person had ~100 split
points which significantly impacted compilation. The more split points you
have the more complex analysis will be in order to determine if some code
is unique to a split point.
 
As comparision I have an app that produces 10MB JS in total per permutation
and compiles fine using 4GB memory. It uses about 12 split points.
 
 
Colin Alworth <colin@colinalworth.com>: Sep 25 06:44AM -0700

Agreed with Jens, definitely look at your split point usage. In the war
that you have, you have a .cache.html file that you mentioned, 4.7MB. In
that same dir, there should be a deferredjs/ directory - can you list its
contents? It should have a directory per permutation (so, just one, named
the same as your .cache.html file), and inside that, there should be some
number of .cache.js files. How many are there, and what is their size range
(like the .gwt.rpc table you made)?
 
Odds are very high that a significant number of them are quite small, and
so shouldn't be created at all, so you can either remove them from your
code (by finding their GWT.runAsync(...) calls), or use the compiler's
built-in feature to try to minimize them, `-XfragmentCount=N`. That N is
treated as a suggestion, and the compiler will create approximately that
many split points in the final output - if that number is substantially
less than the number of GWT.runAsync() calls, you probably will see a
substantial compile time and memory usage improvement.
 
If most/all of the split points are small (say, under 100KB), you might
consider disabling split points entirely to skip this processing step.
There will be an increase in your initial page size, but possibly a
manageable one.
 
But the most important thing when using split points is to measure impact
on the user - when you load the page, watch the Network tab in browser
tools, and see how much you are actually deferring, how many split points
are being loaded, and how big they are. Odds are pretty high that the very
last (going by file name) split point is loaded very soon after page load,
and that this file is one of the biggest if not the biggest, which itself
suggests that some work is necessary to improve your page loading
experience. That split point is the "leftover" chunk, and represents any
code shared by two or more chunks - using the -XfragmentCount feature is
very likely to reduce its size, but modeling how your page loads and
application builds is more complex than can be written in an email.
 
One more simple point: consider turning off the compiler report flag if you
aren't actively using the results, it will take extra memory, compile time,
and disk space. It would be helpful to turn it back on periodically, but
shouldn't be necessary to keep it on all the time for all developers. This
tool assists in some of the "why are my split points the way they are"
debugging, but if the compile doesn't succeed anyway, odds are no one is
looking at it.
 
Finally, GWT 2.6.1 is more than a decade old - if you're actively
developing this application, strongly consider updating.
 
 
 
On Wednesday, September 25, 2024 at 4:40:36 AM UTC-5 Jens wrote:
 
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to google-web-toolkit+unsubscribe@googlegroups.com.

--
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/CABjQu7T32ZasY27zj3VhxFSR413cqPitH8TVMeT%2BX6M9PXqUhQ%40mail.gmail.com.

No comments:

Post a Comment