Thank You
JENS & COLIN for providing your inputs and valueable suggestions. We have
applied the same in our application and here is the result:
currently our defferedJs are as follows:
[image: Screenshot 2024-09-26 140941.png]
but after we removed all split points and only kept some major ones, here
is the result:
[image: Screenshot 2024-09-26 141151.png]
Now! our WAR is compiling (single permutation) in 10.25 mins only. We are
testing our application workflow as many of the differedJS files are
greater than 1 mb. We'll try to reduce the size.
*We again want to express our gratitude to JENS & COLIN for showing the
right path towards the root cause along with the solution.*
Whereas GWT 2.6.1 upgradation is concerned, we would like to say, yes! we
are actively developing the application and are intrested in upgrading GWT
2.6.1. But there are some issues which are required to be addressed. Many
time earlier we have planned the upgradation, but dropped the idea due to
not having the clear answers on bellow mentioned points.
*1.* Which version of GWT we should move to? As many of the latest
technologies are rolling arround and GWT in itself also have released many
versions after 2.6.1. Meanwhile J2CL had also been launched. Migrating a
huge application rapidly is not possible, so we want to be very sure.
*2.* We are using "Apache Netbeans IDE" from a long time and now the team
is also very much famlier with it. Upgraded GWT4NB plugin was missing from
market place. Can we go for upgradation without changing IDE?
*3.* We are using "JDK 1.8". Do we required to upgrade JDK too?
*4.* We are using "PAYARA-WEB-SERVER" in both development + Production
environment. GWT upgraded versions are comming with inbuild JETTY servers.
Can we use "PAYARA-WEB-SERVER" in development after upgradtion or we have
to stick wit JETTY only?
*5.* We are using "ANT build" not "Maven build" means we are not having any
type of POM files.
*6.* We are using sencha (gxt 3.1.1) mainly for GRID functionality.
Upgrading GWT will fall dependency is on SENCHA-GXT and upgraded SENCHA-GXT
is paid. What are its alternative?
*7.* Our application is having GWT standard architecure eg: (client +
shared + server) in the same application. We want to split our application
as client & server seperate. Where we want to move server part in
SPRING-BOOT without any major changes. Is it possible?
For detail discussions we can connect on [email protected]. We welcome
any type of suggestions or involvement on the same.
On Wednesday, September 25, 2024 at 7:14:35 PM UTC+5:30 Colin Alworth wrote:
> 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:
>
>> 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.
>>
>>
>> [email protected] schrieb am Dienstag, 24. September 2024 um 17:58:36
>> UTC+2:
>>
>>> Hi everyone,
>>>
>>> We have stucked in a very strange / awkward situation. Our running GWT
>>> 2.6.1 application started crashing at the time of compilation since 2 days
>>> back.
>>>
>>> We are using netbeans IDE (non-maven). we are sharing our
>>> app-information as follows:
>>> 1. "WAR" SIZE : 591MB
>>>
>>> 2. Total "*.gwt.rpc" files : 891 files (we have attached some of the
>>> *.gwt.rpc files for ref.)
>>> [image: Screenshot 2024-09-24 205607.png]
>>>
>>> 3. "*.cache.html" SIZE : 4.15 MB
>>>
>>> 4. Earlier when WAR was compiling it was taking max 50 minutes for full
>>> comilation (single permutation) on hardware of (64 GB RAM, 4 Core, Xeon (R)
>>> CPU E3-1225 v5 @3.30 GHz, window-server 2019 standard)
>>>
>>> 5. using JVM option -Xmx61440M (gwt-conpilation config attached for ref.)
>>>
>>> 6. Currently we are getting following error:
>>> Compile with -strict or with -logLevel set to TRACE or DEBUG to see all
>>> errors.
>>> Compiling 1 permutation
>>> Compiling permutation 0...
>>> [ERROR] OutOfMemoryError: Increase heap size or lower
>>> gwt.jjs.maxThreads
>>> java.lang.OutOfMemoryError: Java heap space
>>> at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:133)
>>> at java.io.OutputStreamWriter.write(OutputStreamWriter.java:220)
>>> at java.io.Writer.write(Writer.java:157)
>>> at
>>> com.google.gwt.core.ext.soyc.impl.DependencyRecorder.flushOutput(DependencyRecorder.java:136)
>>> at
>>> com.google.gwt.core.ext.soyc.impl.DependencyRecorder.endDependencyGraph(DependencyRecorder.java:70)
>>> at
>>> com.google.gwt.dev.jjs.impl.codesplitter.CodeSplitter.computeComplementCfaForFragments(CodeSplitter.java:325)
>>> at
>>> com.google.gwt.dev.jjs.impl.codesplitter.CodeSplitter.computeExclusivityMapWithFixups(CodeSplitter.java:362)
>>> at
>>> com.google.gwt.dev.jjs.impl.codesplitter.CodeSplitter.execImpl(CodeSplitter.java:480)
>>> at
>>> com.google.gwt.dev.jjs.impl.codesplitter.CodeSplitter.exec(CodeSplitter.java:115)
>>> at
>>> com.google.gwt.dev.jjs.JavaToJavaScriptCompiler.compilePermutation(JavaToJavaScriptCompiler.java:423)
>>> at
>>> com.google.gwt.dev.jjs.UnifiedAst.compilePermutation(UnifiedAst.java:137)
>>> at com.google.gwt.dev.CompilePerms.compile(CompilePerms.java:195)
>>> at
>>> com.google.gwt.dev.ThreadedPermutationWorkerFactory$ThreadedPermutationWorker.compile(ThreadedPermutationWorkerFactory.java:50)
>>> at
>>> com.google.gwt.dev.PermutationWorkerFactory$Manager$WorkerThread.run(PermutationWorkerFactory.java:73)
>>> at java.lang.Thread.run(Thread.java:750)
>>> [ERROR] Out of memory; to increase the amount of memory, use
>>> the -Xmx flag at startup (java -Xmx128M ...)
>>> [ERROR] Unrecoverable exception, shutting down
>>> com.google.gwt.core.ext.UnableToCompleteException: (see previous log
>>> entries)
>>> at
>>> com.google.gwt.dev.ThreadedPermutationWorkerFactory$ThreadedPermutationWorker.compile(ThreadedPermutationWorkerFactory.java:56)
>>> at
>>> com.google.gwt.dev.PermutationWorkerFactory$Manager$WorkerThread.run(PermutationWorkerFactory.java:73)
>>> at java.lang.Thread.run(Thread.java:750)
>>> [ERROR] Not all permutation were compiled , completed (0/1)
>>> F:\users\Avinash\forNewPlugin\aarogya\nbproject\build-gwt.xml:333: The
>>> following error occurred while executing this line:
>>> F:\users\Avinash\forNewPlugin\aarogya\nbproject\build-gwt.xml:482: Java
>>> returned: 1
>>> BUILD FAILED (total time: 39 minutes 36 seconds)
>>>
>>>
>>> We request you all to please provide any help / guidance on the same.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit/73d1c410-0b45-4f72-a859-34c3f04638f1n%40googlegroups.com.
