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



为什么调用外部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 ")

另一方面,当从命令行运行Scala编译器时,就像在shell会话中一样:

scala HelloWorld.scala

打印Hello World需要小于0.5s

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

作为最后一个资源,Java脚本引擎与反映的或字节码编译的Java代码相比有多快?我发现,至少,它们是可以编译的:编译常用的脚本。



选择的解决方案:runtimecompilescala

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

命令行脚本运行程序不是REPL会话;相反,它将代码封装在一个带有main方法的简单对象中,编译并运行它。

相比之下,REPL中的每一个解释行(或可编译的东西)都被包装在一个对象中(导入会话历史,这样您就可以引用过去的结果)。

即使是模REPL启动,这也会对性能产生影响,请参阅此问题。

语法分析器中内置了脚本运行程序的简单包装逻辑。以下是脚本运行程序如何运行编译。或者,看起来这就是-e的处理方式。

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

相关内容

  • 没有找到相关文章

最新更新