In looking at this a little more, it appears the code I listed above while inefficient is not really that slow unless the number of files is huge. That left me wondering why it was a problem for us since we only have ~2500 classes. I popped it into the debugger and saw that it was iterating over 7 million files due to the following method in FileSystemCompiler, which is the real root cause of most our slowness. I bolded the offending line of code

public static String[] generateFileNamesFromOptions(CommandLine cli) { String[] filenames = cli.getArgs(); List<String> fileList = new ArrayList<String>(filenames.length); boolean errors = false; for (String filename : filenames) { if (filename.startsWith("@")) { try { BufferedReader br = new BufferedReader(new FileReader(filename.substring(1))); String file; while ((file = br.readLine()) != null) { fileList.add(file); } } catch (IOException ioe) { System.err.println("error: file not readable: " + filename.substring(1)); errors = true; } } else { *fileList.addAll(Arrays.asList(filenames));* } } if (errors) { return null; } else { return fileList.toArray(new String[fileList.size()]); } }

As you can see it's adding the entire array inside the loop, so you end up with n^2 files. Then combine that with the inefficient iterator when later adding the files to the compilation unit and that's how it ends up being so slow.