optimizationLevel and runAsync

[cblanche34]

GWT version: 2.8.2 Browser (with version): Chrome 64.0.3282.140 Operating System: Linux

---

Description

I use runAsync on a large GWT project, but the default optimization level makes it ineffective :

• With normal optimizationLevel : Full code size : 5 450 Ko Initial download size : 750 Ko Left over code : 3 800 Ko Plus 24 deferred little js (less than 400 Ko).

• With optimizationLevel 1 : Full code size : 5 300 Ko (better) Initial download size : 750 Ko Left over code : 2 185 Ko (better) Plus 24 deferred js with one of 1800 Ko (better)

With normal optimizationLevel, deferred JS are very little, so we don't save bandwidth or browser performance when evaluating the js code.

[niloc132]

Interesting find - I realize this is a large project, but perhaps you can break it down to give us a smaller example to be able to reproduce and fix. Can you run the compiler report (aka SOYC) and look to see which classes are in the split point with optimizationLevel=1, but not in optimizationLevel=9? Also, can you give us the full list of args you pass to the compiler?

Additionally, what do you mean "Plus 24 deferred little js" - is that 24 other split points, for a combined total of ~1.8mb?

[cblanche34]

Yes we put 24 runAsync.

With normal optimizationLevel : 910 KO

Split Points
#   Location        Size (Bytes)    % of total
1   GwtModuleLoader::runAsyncCall       367 268     6,7 %
2   GwtModuleLoader::runAsyncCall         1 575     0,0 %
3   GwtModuleLoader::runAsyncCall           519     0,0 %
4   GwtModuleLoader::runAsyncCall           400     0,0 %
5   GwtModuleLoader::runAsyncCall           448     0,0 %
6   GwtModuleLoader::runAsyncCall       301 834     5,5 %
7   GwtModuleLoader::runAsyncCall           101     0,0 %
8   GwtModuleLoader::runAsyncCall         5 304     0,1 %
9   GwtModuleLoader::runAsyncCall       100 360     1,8 %
10  GwtModuleLoader::runAsyncCall        28 767     0,5 %
11  GwtModuleLoader::runAsyncCall           102     0,0 %
12  GwtModuleLoader::runAsyncCall         9 315     0,2 %
13  GwtModuleLoader::runAsyncCall           102     0,0 %
14  GwtModuleLoader::runAsyncCall           102     0,0 %
15  GwtModuleLoader::runAsyncCall        38 483     0,7 %
16  GwtModuleLoader::runAsyncCall         6 962     0,1 %
17  GwtModuleLoader::runAsyncCall           102     0,0 %
18  GwtModuleLoader::runAsyncCall        32 915     0,6 %
19  GwtModuleLoader::runAsyncCall        17 697     0,3 %
20  GwtModuleLoader::runAsyncCall        17 814     0,3 %
21  GwtModuleLoader::runAsyncCall           102     0,0 %
22  GwtModuleLoader::runAsyncCall           102     0,0 %
23  GwtModuleLoader::runAsyncCall           102     0,0 %

With level 1 : 2,3 MO

Split Points
#   Location        Size (Bytes)    % of total
1   GwtModuleLoader::runAsyncCall       1 737 459   32,7 %
2   GwtModuleLoader::runAsyncCall           1 715    0,0 %
3   GwtModuleLoader::runAsyncCall             657    0,0 %
4   GwtModuleLoader::runAsyncCall             400    0,0 %
5   GwtModuleLoader::runAsyncCall             448    0,0 %
6   GwtModuleLoader::runAsyncCall         380 998    7,2 %
7   GwtModuleLoader::runAsyncCall             101    0,0 %
8   GwtModuleLoader::runAsyncCall           5 974    0,1 %
9   GwtModuleLoader::runAsyncCall          94 419    1,8 %
10  GwtModuleLoader::runAsyncCall          28 520    0,5 %
11  GwtModuleLoader::runAsyncCall             102    0,0 %
12  GwtModuleLoader::runAsyncCall           9 210    0,2 %
13  GwtModuleLoader::runAsyncCall             102    0,0 %
14  GwtModuleLoader::runAsyncCall             102    0,0 %
15  GwtModuleLoader::runAsyncCall          36 510    0,7 %
16  GwtModuleLoader::runAsyncCall           6 440    0,1 %
17  GwtModuleLoader::runAsyncCall             102    0,0 %
18  GwtModuleLoader::runAsyncCall          32 457    0,6 %
19  GwtModuleLoader::runAsyncCall          16 440    0,3 %
20  GwtModuleLoader::runAsyncCall          19 825    0,4 %
21  GwtModuleLoader::runAsyncCall             102    0,0 %
22  GwtModuleLoader::runAsyncCall             102    0,0 %
23  GwtModuleLoader::runAsyncCall             102    0,0 %

[cblanche34]

Most of sources which goes to left over in the normal optimization are using a lib which decode objects from JSON.This lib has a map of all objects which can be decoded. It seems that after level 2 of optimizations, the class which uses this lib goes to left over.

[jnehlmeier]

Doesn't sound too surprising to me. Could very well happen that your code ends up in a situation that is not optimal for split points. I guess type tightening could cause that for example. Given that ordering of optimization technics is fixed, I would always run multiple optimization passes so that early optimization technics can benefit from later ones of the previous pass.

Personally I would always use -optimizationLevel 9 which does 100 optimization passes OR aborts earlier if the Java AST does not change anymore significantly. If you use any level lower than 9 then the number you specify is the exact number of optimization passes that will be done.