Hello all,
I'm having some idle time and thought I waste your time also by
sharing some experiments while trying to speed up a GWT
compilation ;-)
The system: a core i3 laptop, 2 cores with Hyperthreading at 2,4 GHz
(thus, 4 virtual CPUs) with 6GB RAM running under Ubuntu 10.10 64bit
with the Sun/Oracle 1.6 jdk.
The application consists of three modules which result in 16
permutations each. I am quoting the compilation settings and JVM
arguments. Legend: local workers is the -localWorkers argument to the
GWT compiler, processes is the number of gwtcompiler instances running
(remember: I have 3 modules, so in theory I could be running 3
gwtcompilers in parallel). The elapsed time is measured in
minutes'seconds" :
1) setup: 2 local workers, 1 process, vmargs: -Xmx384m
time : 3'29"
2) setup: 2 local workers, 1 process, vmargs: -Xmx512m
time : 3'25"
3) setup: 2 local workers, 1 process, vmargs: -Xmx1024m -Xms1024m
time : 3'25"
4) setup: 3 local workers, 1 process, vmargs: -Xmx512m -Xms1024m
time : 3'40"
5) setup: 4 local workers, 1 process, vmargs: -Xmx512m -Xms1024m
time : 3'53"
6) setup: 1 local workers, 2 process, vmargs: -Xmx512m -Xms1024m
time : 3'11"
7) setup: 1 local workers, 3 process, vmargs: -Xmx512m -Xms1024m
time : 2'40"
8) setup: 1 local workers, 3 process, vmargs: -Xmx1024m -Xms1024m
time : 2'35"
9) setup: 1 local workers, 3 process, vmargs: -server -Xmx1024m -
Xms1024m
time : 2'28"
10) setup: 1 local workers, 3 process, vmargs: -d64 -server -Xmx1024m -
Xms1024m
time : 2'38"
A quick walkthrough of the results: The runs 1-5 show that extra local
workers don't seem to efficiently use the extra cores.
Run 6 shows a significant improvement by not using local workers but
just launching two compilers in parallel.
Run 7 shows an even larger improvement by running 3 compilers in
parallel. This is not completely surprising, as run 6 would compile
two modules at the same time, queuing the 3rd module after the first
two.
Run 8 again is somewhat surprising, because we observe a speedup due
to a larger heap given to the compiler, while run 3 attempted
unsuccessfully the same.
Run 9 puts the JVM into -server mode which further speeds up the
compilation.
Run 10 puts the JVM into 64bit mode (by default it runs in 32bit mode,
even on 64bit systems) which slows the compilation down by 10 seconds.
My interpretation of the result: the gwt compiler splits compilation
into two phases, an analysis phase and the permutation compilation
phase. Only the latter benefits from local workers, the first phase is
more or less single-threaded. For my application (with the rather low
permutation count of 16) the analysis phase takes up a large part
(around one third of the total compilation time) during which the
second core remains unutilised. By running compilers in parallel, the
second core is also utilised, which decreases the total time spent on
the compilation. Last not least, a significant improvement comes from
using the -server JVM, which however is not the case when using local
workers which is not shown here - I suspect the reason to be the
incidental size of my application where -server and -client are at
par. I believe that the reason for the good results with -server and
no local threads is the long warmup phase needed by the server JVM
which impacts negatively on local workers since the gwtcompiler create
for each permutation a new JVM instance.
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
