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 nilo...@gmail.com: > 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 viny...@gmail.com 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. >>> >>> viny...@gmail.com 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 google-web-toolkit+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/f75d442d-5b26-425f-888c-8ffc0f258945n%40googlegroups.com.
