tbh, I've never worked with split points before. What would be the actual problem be if splitpoints are not used - besides from the initial load times?
Op vrijdag 1 april 2022 om 17:46:40 UTC+2 schreef [email protected]: > Split points are amazingly expensive to compute (in both CPU and memory) - > I would definitely remove all split points currently under 10KB, and > strongly consider removing all under 100KB, at least for an application of > that size. Odds are excellent that your 4043KB file is your "leftovers" > split point (you can confirm this by checking if the name of the file is > the largest number in that directory) - if so, it is quite possible that > removing other tiny split points will decrease the size of the leftovers > and increase the size of the other larger split points. It may increase the > initial download size as well, which could tell you that it could be wise > to carefully put some back, but taking care to merge related split points > (for example, using GWT.runAsync(Class, RunAsyncCallback) to tell the > compiler that more than one RunAsyncCallback should be merged as the main > file). > > Consider the order that your files must load in order for the application > to start up - first, the 1.7MB file loads, and the app is usable until the > first split point loads. Does that first split point load instantly? Does > more than one load right away before the app can be used? Consider merging > those split points, or entirely removing them, if they don't provide some > concrete benefit (like allowing the user to start logging in while the rest > of the app is still downloading, etc). > > Next, before the very first split point can be loaded, the "leftovers" > split point is loaded - the split point with the biggest number, in your > case this would be 756.cache.js (as of your last message). This must be > downloaded and run before any other split point can be loaded - if this is > your biggest one by a factor of of almost 10, it might not even make sense > to have more than a handful of split points, unless you can find a way to > bring that leftover size down, or possible merge it into the initial split > point. > On Friday, March 4, 2022 at 8:08:11 AM UTC-6 [email protected] wrote: > >> First of all we are very-very thankful to VIE, FRANK & JENS for their >> valuable suggestions and are sorry for late reply. As we were busy in >> applying the solutions suggested by you people. >> >> *AS THE RESULT:-* >> 1. As we have already using "*gwt.compiler.jvmargs=-Xmx61440m*" so we >> could not get what VIE mean to say. >> 2. As per the suggestion of FRANK we change the logLevel and got the >> error details and found that some server side classes has been used eg: >> "*Line 18: No source code is available for type >> java.util.regex.Pattern; did you forget to inherit a required module?"* >> * We solved the bugs one-by-one BUT this also not resolved our >> primary problem*. >> 3. As per the suggestion of JENS >> 3.1. We used -optimize *BUT this also not resolved our primary >> problem*. >> 3.2. We tried to lower down the split points by 100. As we get near >> to 756 *.cache.js files. The code started to compile in 35-40 minutes. >> * So! the split points were the culprit.* >> >> >> *Now our war file is compiling in 30-40 minutes and we are planning to >> lower down the split points more.* >> >> *WE ARE VERY THANKFULL TO ALL OF YOU. AS YOUR VALUABLE SUGGESTION HAD >> SAVED US.* >> >> On Thursday, March 3, 2022 at 6:03:27 AM UTC+5:30 Jens wrote: >> >>> As already said the first thing you should do is to use -strict. This >>> makes sure GWT compiler does not ignore compile errors. Given you have 12 >>> compile errors, you want to fix them first. >>> >>> Next it looks like you have a lot of split points if you have 856 >>> *.cache.js files. Given that 817 of these files are less than 100kb and >>> these files are usually gzipped by the web server before transferring to >>> the client browser, you should try to reduce the amount of split points. I >>> could imagine that analyzing the code for split point calculation might be >>> the culprit. >>> >>> There is also an -optimize option for the GWT compiler with values 0 - 9 >>> (0 = no optimizations, 9 = aggressive). I don't recall the default value >>> but if it is 9 then it will do an optimize loop on the code AST until the >>> AST does not change anymore. In rare cases this can end up in an endless >>> loop. Using -optimize 8 usually fixes the issue as the compiler will do at >>> most 8 optimize loops then. So you might want to try that as well. >>> >>> I have a compiled app that is roughly half the size of yours (about 15 >>> MB) and it compiles fine with just 8 GB Ram. But it only has about 20 split >>> points. Using 64GB seems overkill in your case. Maybe you could also try >>> making a heap dump and analyze it in Eclipse memory analyzer to see what is >>> consuming all your heap memory. However analyzing a 64GB heap dump won't be >>> fun either. >>> >>> -- J. >>> >>> [email protected] schrieb am Dienstag, 1. März 2022 um 16:27:41 UTC+1: >>> >>>> Hi, >>>> >>>> We are having a quite big project, every thing was going in control but >>>> from last few days our GWT project is crashing while building WAR (with >>>> error out of memory). >>>> "*Compiling module project2.**Project2* >>>> >>>> >>>> >>>> >>>> * Validating units: Ignored 12 units with compilation errors in >>>> first pass.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.maxThreadsjava.lang.OutOfMemoryError: Java heap space*" >>>> >>>> *System (PC) configuration on which we are building WAR is:* >>>> OS = WINDOWS SERVER 2019 >>>> PROCESSOR = XEON (R) CPU E3-1225 V5 @ 3.3Ghz >>>> CORE = 4 >>>> RAM = 64GB >>>> HARD DISK = HDD >>>> C (OS drive) = 203GB free of 243GB >>>> E (drive) = 501GB free of 642GB >>>> F (drive) = 467GB free of 976GB >>>> >>>> *rest please find the PC images attached.* >>>> >>>> >>>> *GWT build configuration is:* >>>> gwt.module=project1.Project1 project2.Project2 >>>> gwt.output.dir=/org.yournamehere.Main >>>> gwt.compiler.output.style=OBFUSCATED >>>> gwt.compiler.jvmargs=-Xmx61440m >>>> gwt.compiler.local.workers=1 >>>> gwt.compiler.logLevel=INFO >>>> gwt.shell.output.style=OBFUSCATED >>>> gwt.shell.logLevel=TRACE >>>> >>>> gwt.shell.jvmargs=-Xmx61440m >>>> gwt.shell.java= >>>> gwt.version=2.6 >>>> gwt.shell.code.server.port=9997 >>>> gwt.shell.port=8888 >>>> >>>> *rest please find the gwt.properties file attached.* >>>> >>>> >>>> *WAR file info:* >>>> >>>> *.WAR (Size on disk) = 577MB >>>> >>>> *project1.Project1* >>>> *.gwt.rpc (count) = 1 >>>> *.gwt.rpc (size) = 8kb >>>> *.cache.html (size) = 335kb >>>> *.nocache.js = 6kb >>>> >>>> *project2.Project2* >>>> *.gwt.rpc (count) = 876 >>>> *.gwt.rpc (size) = 9.76MB >>>> *.gwt.rpc (max) = 19kb - 11kb (158 files), 10kb - 8kb (718 files) >>>> *.cache.html (size) = 1713kb >>>> *.nocache.js = 6kb >>>> deferredjs\4D7A0074D70FA749A45BC16CDEAAFFE3\*.cache.js (count) = 856 >>>> deferredjs\4D7A0074D70FA749A45BC16CDEAAFFE3\*.cache.js (size) = 28.6MB >>>> deferredjs\4D7A0074D70FA749A45BC16CDEAAFFE3\*.cache.js (max) = 4043kb(1 >>>> file), 446kb - 101kb (38 files), 98kb - 1kb (817 files). >>>> >>>> >>>> >>>> *WE REQUEST TO ALL PLEASE HELP! AS DELIVERY OF THE WAR IS REQUIRED ON >>>> URGENT BASIS.* >>>> >>>> >>>> >>>> >>>> >>>> -- 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/f75d442d-5b26-425f-888c-8ffc0f258945n%40googlegroups.com.
