JDK-8044689 : Nashorn is slower than Rhino on B-Tree test
  • Type: Bug
  • Component: core-libs
  • Sub-Component: javax.script
  • Affected Version: 8u5,8u40
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: x86
  • Submitted: 2014-06-03
  • Updated: 2015-10-05
  • Resolved: 2015-10-05
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9Fixed
Related Reports
Blocks :  
JDK-8025435 - Specialized library functions for optimistic typing
Sub Tasks
JDK-8061391 :  
String.concat needs to have optimistic builtin versions - Resolved
JDK-8062141 :  
Various performance issues parsing JSON - Resolved
Description
A DESCRIPTION OF THE REQUEST :
Using the B-Tree script available at

https://github.com/ysangkok/js-clrs-btree

and running runnashorn.sh or runrhino.sh, each iteration is consistently slower in Nashorn than it is in Rhino. After disabling the calls into Java code, it is still slower. 

JUSTIFICATION :
Nashorn promised improved performance over Rhino. The main rationale behind Nashorn is benefiting from JSR-292: Dynamic Languages on the JVM aka InvokeDynamic. Since Nashorn uses this technology, which Rhino does not, it should be possible to achieve superior performance. Since superior performance has not been achieved, this bug is filed.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Performance ideally as good as Rhino.
ACTUAL -
On my machine, Nashorn is consistently 1/3 slower than Rhino.
Comments
On my computer Nashorn now stabilises at about 120 milliseconds per iteration, Rhino at about 200. I think we can consider this good enough.
05-10-2015
Defer to 9? I've fixed half of this problem. See the subtask. JSON parsing speedups is a rather large project.
24-11-2014
Hannes is working on the JSON parse part, so I'm reassigning the umbrella CR to him as well. Assign it back if you feel this is inappropriate. The concat fix is now checked into 9 and backported to 8u-dev
27-10-2014
By using my new optimistic builtin framework to optimize concat for native arrays to native arrays, I can get this down to ~140 which is definitely below rhino. more bottlenecks as, as I said in the JSon properties, so this looks promising. This requires JDK-8025435 though
25-09-2014
This is definitely not 1/3rd slowdown anymore. It's 220 ms on Nashorn per iteration and 180 on Rhino. The main bottleneck seems to be in an array setter callsite that gets box despite the optimistic types and the findProperty called from the JSON processor. Investigating further.
25-09-2014
I've investigate with optimistic types, latest jdk 9 and there is still some slowdown ~��25% Rhino iterations stabilize at ~200 ms and Nashorn at ~250ms. I'm not sure how much a codegen bottleneck this is and how much is runtime. Will investigate further.
04-06-2014
git repo is accessible - I've not verified numbers b/w rhino vs nashorn. But worth checking if optimistic compilation helps or not.
04-06-2014