Proposed javac argument processing performance improvement

David Schlosnagle schlosna at
Thu Jun 16 20:16:22 PDT 2011

On Tue, Jun 14, 2011 at 7:34 PM, Jonathan Gibbons
<jonathan.gibbons at> wrote:
> David,
> Looking at your patch, you take a hit at the end by converting the Set to a
> List by way of an array.  At a minimum, it would be worth overloading
> List.from to accept an Iterable<A> -- that would allow you to eliminate the
> intermediate array. For bonus points, you could change the return type of
> processArgs to Iterable<File> and avoid the copy altogether. However, in
> that case, you would need to fix up a couple of isEmpty() calls in Main. The
> primary use of the result is in, which already accepts
> Iterable<File>.  There are no other uses that I can see within the main
> javac source code. I found 3 uses in the regression tests that would be
> unaffected.


Thanks for the comments. I had debated refactoring the method
signature, but held off initially. This weekend I'll try to put
together a patch with Iterable<File> and gather some more realistic
stats across a few platforms. I did a few initial tests on a medium
sized build and the results were very promising -- the total javac
execution time for compiling a 5,522 file module went from 54 seconds
to 39 seconds, a reduction of 15 seconds all due to reducing
processArgs execution time from 15.890 seconds to 0.350 seconds. For
smaller numbers of input files, the gains were proportional to the
number of input files. With the Iterable changes, I hope to see even
more gains.

> I believe there are a couple of regression tests that need to be fixed up if
> you change the type of JavaCompiler.filenames.

I'll include these changes in the patch and run jtreg. Do you
typically create performance related regression tests? Are there any
new tests you'd recommend for me to add?

On a side note, are there any langtools jtreg tests that are currently
known to fail? I saw 3 failed javadoc tests that seem to be Mac OS X
specific and probably related to

- Dave

More information about the compiler-dev mailing list