Performance 纳肖恩比犀牛慢3倍，如何优化？

我正在将我的应用程序中的一些代码从Rhino移植到Nashorn（主要是为了跟上现代时尚，而不是Rhino中缺少功能），Nashorn的性能非常差

我的应用程序在运行时编译的文件较少（内容是动态的，因此无法预编译）。这在启动时执行一次，每次在运行时检测到更改时执行一次

Rhino提供了大约4-5秒的一致性能（JS脚本加载了最高的Rhino优化）

Nashorn提供了一些非常奇怪的结果-大约15-17秒，但在第10次迭代和大约10分钟的时间后，性能变得相当好-大约3秒。但由于初始速度缓慢，我的Nashorn应用程序的启动时间通常比Rhino长约30秒（编译的文件也较少）

因此，问题是：

我该怎么做强制Nashorn立即执行脚本的最高优化，而不是在10-20次迭代之后

---

下面是日志文件中的计时

2015-11-11 09:29:16,419 compile(less, styles.less)  = 15179ms
--------------------------------------------------------------
   15.179       %  compile (styles.less)
--------------------------------------------------------------
   13.940   91.8%  less-rhino-ji.js lessFileToCss(styles.less)
    1.227    8.0%  YUICompressor minify(styles.less)

2015-11-11 09:30:12,900 compile(less, styles.less)  = 13274ms
--------------------------------------------------------------
   13.274       %  compile (styles.less)
--------------------------------------------------------------
   11.605   87.4%  less-rhino-ji.js lessFileToCss(styles.less)
    1.664   12.5%  YUICompressor minify(styles.less)

2015-11-11 09:30:43,705 compile(less, styles.less)  = 6906ms
--------------------------------------------------------------
    6.906       %  compile (styles.less)
--------------------------------------------------------------
    5.695   82.4%  less-rhino-ji.js lessFileToCss(styles.less)
    1.205   17.4%  YUICompressor minify(styles.less)

2015-11-11 09:31:09,194 compile(less, styles.less)  = 6041ms
--------------------------------------------------------------
    6.041       %  compile (styles.less)
--------------------------------------------------------------
    4.622   76.5%  less-rhino-ji.js lessFileToCss(styles.less)
    1.412   23.3%  YUICompressor minify(styles.less)

2015-11-11 09:31:49,558 compile(less, styles.less)  = 7619ms
--------------------------------------------------------------
    7.619       %  compile (styles.less)
--------------------------------------------------------------
    3.056   40.1%  less-rhino-ji.js lessFileToCss(styles.less)
    4.555   59.7%  YUICompressor minify(styles.less)

2015-11-11 09:36:25,586 compile(less, styles.less)  = 5226ms
--------------------------------------------------------------
    5.226       %  compile (styles.less)
--------------------------------------------------------------
    4.104   78.5%  less-rhino-ji.js lessFileToCss(styles.less)
    1.116   21.3%  YUICompressor minify(styles.less)

2015-11-11 09:36:40,745 compile(less, styles.less)  = 3839ms
--------------------------------------------------------------
    3.839       %  compile (styles.less)
--------------------------------------------------------------
    2.664   69.3%  less-rhino-ji.js lessFileToCss(styles.less)
    1.169   30.4%  YUICompressor minify(styles.less)

2015-11-11 09:37:02,876 compile(less, styles.less)  = 3074ms
--------------------------------------------------------------
    3.074       %  compile (styles.less)
--------------------------------------------------------------
    1.948   63.3%  less-rhino-ji.js lessFileToCss(styles.less)
    1.120   36.4%  YUICompressor minify(styles.less)

2015-11-11 09:37:29,140 compile(less, styles.less)  = 4773ms
--------------------------------------------------------------
    4.773       %  compile (styles.less)
--------------------------------------------------------------
    3.682   77.1%  less-rhino-ji.js lessFileToCss(styles.less)
    1.085   22.7%  YUICompressor minify(styles.less)

2015-11-11 09:37:51,768 compile(less, styles.less)  = 2761ms
--------------------------------------------------------------
    2.761       %  compile (styles.less)
--------------------------------------------------------------
    1.661   60.1%  less-rhino-ji.js lessFileToCss(styles.less)
    1.094   39.6%  YUICompressor minify(styles.less)

2015-11-11 09:38:19,053 compile(less, styles.less)  = 2743ms
--------------------------------------------------------------
    2.743       %  compile (styles.less)
--------------------------------------------------------------
    1.639   59.7%  less-rhino-ji.js lessFileToCss(styles.less)
    1.098   40.0%  YUICompressor minify(styles.less)

---

更新： 根据Olipro的建议，我用以下参数启动了流程：

java -XX:+UnlockDiagnosticVMOptions -XX:+PrintCompilation ...

结果不是绝对清楚的-Nashorn生成的类的名称类似于

jdk.Nashorn.internal.scripts.Script$Recompilation$438$121292A$^eval\：L:3187$toCSS

，但是仅通过方法名，我看到在该测试中CSS文件的最长编译（4.4秒）期间，方法

toCSS（）

被重新编译了5次，似乎有两个后台线程并行编译了同一方法的不同版本（我觉得有点奇怪）-很可能这确实是性能差的根本原因

仍然-没有提示如何提高启动性能：(

日志中的行（=从jvm开始的毫秒）：

---

这听起来像是Java的JIT的牺牲品。一般来说，Java在完成对它的评测之前不会进行JIT代码，这听起来与这种情况一模一样

现在，您可以在启动JRE时传递一些选项，以强制它立即使用

-Xcomp

以本机方式编译所有内容，或在使用

-XX:CompileThreshold

以较少的次数运行后执行，但通常不推荐这两种方法

---

如果JVM实例所做的只是充当一个美化的编译器，那么您可以不必尝试

-Xcomp

，但如果您的程序预期寿命很长，就让它去吧。无论如何，我当然建议您传递

-server

我尝试过使用

-Xcomp

，最终结果非常重要性能更差。总体启动时间从1:40分钟增加到15:30。因此，不确定JVM在幕后会发生什么，但在我的情况下，

-Xcomp

不会优化任何内容。对，

-Xcomp

导致JVM将所有内容编译为本机代码，因此不推荐使用。我建议查看操作注意：并启用编译活动的日志记录，这样您就可以了解Java是如何使编译过程逐步加快的。

11100 5677 jdk.nas...tion$438$121292A$\^eval\_::L:3187$toCSS (103 bytes)
11119 5682 jdk.nas...tion$446$150019A$\^eval\_::L:4147$toCSS (137 bytes)
11377 5677 jdk.nas...tion$438$121292A$\^eval\_::L:3187$toCSS (103 bytes)   made not entrant
11507 5677 jdk.nas...tion$438$121292A$\^eval\_::L:3187$toCSS (103 bytes)   made zombie
11932 5798 jdk.nas...tion$438$121292A$\^eval\_::L:3187$toCSS (103 bytes)
13381 5798 jdk.nas...tion$438$121292A$\^eval\_::L:3187$toCSS (103 bytes)   made not entrant
14272 5798 jdk.nas...tion$438$121292A$\^eval\_::L:3187$toCSS (103 bytes)   made zombie
14778 5682 jdk.nas...tion$446$150019A$\^eval\_::L:4147$toCSS (137 bytes)   made not entrant
14860 6049 jdk.nas...tion$438$121292A$\^eval\_::L:3187$toCSS (103 bytes)
14890 6056 jdk.nas...tion$446$150019A$\^eval\_::L:4147$toCSS (137 bytes)
15019 5682 jdk.nas...tion$446$150019A$\^eval\_::L:4147$toCSS (137 bytes)   made zombie
15223 6162 jdk.nas...tion$457$121460$\^eval\_::L:3187$toCSS$isEmpty (31 bytes)