为什么调用外部 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 会话中一样从命令行运行 Scala 编译器时：

scala HelloWorld.scala

打印一个 Hello World 需要 不到 0.5 秒。

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

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

---

---

选择的解决方案： runtimecompilescala.

Answer 1

还有很多未说明的内容（例如内存设置），但您是在比较苹果和橙子。

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

相比之下，REPL 中的每个解释行（或可编译的东西）都包装在一个对象中（导入会话历史记录，以便您参考过去的结果）。

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

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

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