Very slow compiler?

Mon Sep 25 14:27:00 GMT 2000

Bryce McKinlay wrote:
> [bryce@hokkaido libgcj]$ time gcj -C libjava/java/io/ObjectStreamConstants.java
> 0.03user 0.00system 0:00.07elapsed 42%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (475major+302minor)pagefaults 0swaps

Here gcj using libgcj.zip for class definition files. This command won't work
unless you have an existing installation of libgcj (or specify a classpath
pointing to the source tree).
> [bryce@hokkaido libjava]$ time gcj -C java/io/ObjectStreamConstants.java
> 2.86user 0.57system 0:10.72elapsed 31%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (482major+3100minor)pagefaults 0swaps

This time gcj finds the source tree (since the default classpath is `.') and
uses Java sources in preference to bytecode for class definitions.
Obviously parsing source is more expensive than loading bytecode. Moreover,
inner classes will be parsed as a side effect of parsing source, so there may be
more classes mentioned in jc1's verbose output.
When building libgcj, there is no choice but to parse source files at first
since libgcj.zip does not yet exist (looking at a prior installation is a bug
IMHO).
(That's not actually quite true. Compiling to bytecode in topological order,
i.e. starting with java.lang.Object, should be more efficient. I haven't tried
it.)
> Further investigation running jc1 without "-quiet" shows that it is looking at hundreds of class files that it shouldn't:
>> interface java.io.ObjectStreamConstants 
> class java.io.SerializablePermission
> [snip]

Are you sure all of these classes are not referenced directly or indirectly from
ObjectStreamConstants? FWIW, I tried your example and found 176 classes and
interfaces loaded... the same with "javac -verbose" yielded 163.
--
Jeff Sturm
jeff.sturm@commerceone.com