That's the only reason I use split points, to speed up load times.  I split 
the admin pages, from the public pages, so the public don't need to d/l all 
the admin JS.

On Sunday, 3 April 2022 at 3:32:01 am UTC+10 [email protected] wrote:

> 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/b1bacd0c-2fcb-4c72-960c-0c391c5cbc29n%40googlegroups.com.

Reply via email to