scala的ant fsc任务的速度

我有一个蚂蚁文件，我用来编译我的scala项目。我正在使用fsc，它可以避免2?3秒钟，我的核心2需要加载编译器。
我的问题是：蚂蚁fsc任务确实会产生相同的2?3秒的惩罚，据我所知。这是非常讨厌的，因为有专门的fsc是因为这个原因。这是非常烦人的，因为它是真正的开始时间，而不是处理时间，所以我不得不等待3秒在fsc任务，即使没有什么可以重新编译。每一次，它变得更加严重。

我的调查似乎显示大部分时间都是用在scala-compiler.jar上。实际上，由于它们直接运行编译器，所以scalac和fsc任务需要这一点。此外，从ant任务的类路径中删除scala-compiler.jar结果当然是因为缺少依赖关系而导致任务失败。
在逻辑上，fsc任务只是连接到我想的编译d?mon，所以它不应该需要依赖，但我想这是关于它如何实现(fsc任务从scala任务继承)。也许会在下一个版本。

目前我正在查看的解决方案是将fsc任务重写为应用任务，并手动调用fsc。那我不会有延误。只能手动重做scala中包含的任务专门处理的工作，可惜。

有没有人有这个问题的经验？在我的分析中有什么问题吗？你能建议一个比我计划实施的更好的解决方案吗？

作为参考，这里是我的任务看起来(是的，它编译一个android项目)：

<target name="compile-scala" description="Compile scala files">
  <taskdef resource="scala/tools/ant/antlib.xml" classpath="${scala-library.jar}:${scala-compiler.jar}" />
  <mkdir dir="${out.classes.absolute.dir}" />
  <fsc encoding="utf-8" deprecation="on" destdir="${out.classes.absolute.dir}">
    <src>
      <dirset dir="." includes="src"/>
      <dirset dir="." includes="gen"/>
    </src>
    <classpath>
      <pathelement location="${android.jar}" />
      <fileset dir="${sdk.dir}/tools/lib" includes="*.jar" />
    </classpath>
  </fsc>
</target>

编辑：这是应用的任务看起来像。似乎工作然而，这个问题仍然令人满意，所以问题依然存在。

<target name="fast-compile-scala"
    description="Compile scala files without loading the compiler inside ant">
  <mkdir dir="${out.classes.absolute.dir}" />
  <apply executable="fsc" failonerror="true" parallel="true">
    <arg value="-encoding" />
    <arg value="utf-8" />
    <arg value="-deprecation" />
    <arg value="-dependencyfile" />
    <arg value="${out.classes.absolute.dir}/${scala.deps}" />
    <arg value="-g:vars" />
    <arg value="-d" />
    <arg value="${out.classes.absolute.dir}" />
    <arg value="-make:transitivenocp" />
    <arg value="-classpath" />
    <arg value="${android.jar}:${out.classes.absolute.dir}" />
    <!-- <arg value="-optimize" /> -->
    <!-- <arg value="-verbose" /> -->
    <!-- <arg value="-explaintypes" /> -->
    <fileset dir="src" includes="**/*.scala" />
    <fileset dir="src" includes="**/*.java" />
    <fileset dir="gen" includes="**/*.java" />
  </apply>
</target>

再次编辑：
上面的工作，但我发现它有一个非常严重的限制。当文件数量增加时，上述任务受到参数数量和/或命令行长度的限制。在linux或mac操作系统下，一个好的shell，你可以走得很远，而不用打这个墙，但在windows下，几十个文件是所有需要的，以防止上述的工作。添加一个选项来指定文件作为相对路径，而不是绝对给出一些呼吸，但不是太多。根据依赖关系在几个命令中分割文件不是一个现实的选择，因为它是一项相当繁重的任务，并且需要在文件结构更改时进行更新。所以对于小项目而言，上述方案主要解决这个问题，对于任何一个可以承受的规模的项目来说都是不会有帮助的