Re: PATCH: Speed up libgcj build

[Jeff Sturm <jeff dot sturm at appnet dot com>]

Bryce McKinlay wrote:
> This patch speeds up the .java->object file stage of the libgcj build
> quite a lot. It appears that passing the -I flag to gcj forced it to
> only parse .java source files and not use the already-built .class files
> for its dependencies (which is much faster). With this, the time to
> build java/lang/String.java, for example, goes from about 1.5 seconds to
> 90ms for me.

I think Alex said the -I flag was for inlining methods across classes.  But
since inlining doesn't really work yet, I agree you're better off without it. 
And unless you use -O2 I don't think you'll get inlining anyway.

In the long term we ought to be able to inline either source or bytecode.

> 1. Running "sh ./libtool --mode=compile" for every single .java file is
> now actually far slower than running the compiler itself. I really wish
> we could avoid it.

You should see libtool run on a show shell (e.g. bash under Cygwin).

I really, really wish libtool ran in perl, or something with a little speed...

> 2. Can someone remind me why the .java->.class stage was changed to run
> gcj separately for every file? This is now the slowest part of the
> compile by far. At least with the old way there was a chance that "gcj
> -C" would one day be upgraded so that it produces .class files as it
> traverses its dependencies (rather than parse all the source code again,
> and again, and again...)

I haven't found it to be that slow: about 1s per class.  Of course jc1 runs once
for each class, just as it did before.

Changing the compile order might help.  If java.lang.Object were compiled first,
it wouldn't perhaps have to be reparsed for each class.

> -GCJCOMPILE = $(LIBTOOL) --mode=compile $(GCJ) -fassume-compiled -fclasspath=$(here) -L$(here) $(JC1FLAGS) -c
> +GCJCOMPILE = $(LIBTOOL) --tag=GCJ --mode=compile $(GCJ) -fassume-compiled -fclasspath=$(here) -L$(here) $(JC1FLAGS) -c

What is --tag=GCJ for?

--
Jeff Sturm
jeff.sturm@commerceone.com