scala - 为什么调用外部 scala 编译器比使用运行时解释器库更快？

Question

为什么调用外部 scala 编译器比使用运行时解释器库更快？
在下面的代码中 几乎需要 2 秒 来预热解释器。

val out = new PrintStream(new FileOutputStream("/dev/null"))
val flusher = new java.io.PrintWriter(out)
val interpret = {
   val settings = new scala.tools.nsc.GenericRunnerSettings(println _)
   settings.usejavacp.value = true
   new scala.tools.nsc.interpreter.IMain(settings, flusher)
}
interpret.interpret(" ") //   <-- warming up
interpret.interpret(" Hello World ")

另一方面，当像在 shell session 中一样从命令行运行 Scala 编译器时:

scala HelloWorld.scala

需要 小于 0.5s 打印一个 Hello World。

我试图在运行时解析+执行字符串中给出的一些 Java、Scala 或类似代码(它是一个脚本解释器，即在我的应用程序执行期间它只会运行一次)。
Scala 代码显然会更好，但前提是它可以与 Java 选项一样快。
有没有比 nsc.interpreter 和外部编译器更快的替代方法来在运行时从字符串执行代码？
我能找到的最好的是 Janino；它比 Scala 编译器更快，并且不需要 JDK(一个非常有趣的特性)。

作为最后的资源，速度有多快 Java Scripting Engines与反射或字节码编译的 Java 代码相比？我发现，至少，它们可以编译: Compiling oft-used scripts .



选择的解决方案:
runtimecompilescala .

Answer 1

有很多事情没有说明(比如内存设置)，但你是在比较苹果和橘子。

命令行脚本运行程序不是 REPL session ；相反，它使用 main 方法将您的代码包装在一个简单的对象中，编译并运行它。

相比之下，REPL 中的每个解释行(或可编译的东西)都包含在一个对象中(导入 session 历史，以便您可以引用过去的结果)。

即使是模 REPL 启动，这也会影响性能，请参阅 this issue .

脚本运行器的简单 wrap-it 逻辑内置于解析器中。 Here is how脚本运行器运行编译。或者，它看起来像 this is how -e is handled.

编辑:您对问题的评论暗示您确实想要 fsc 编译服务器行为。启动 fsc 并使用 the compile client .