-
Bug
-
Resolution: Fixed
-
P4
-
8u25
-
b28
-
x86_64
-
linux_ubuntu
A DESCRIPTION OF THE REQUEST :
For some reason inserting items by key in a javascript object is a lot slower on Nashorn than in other javascript engines.
When measuring the time it takes to add items to the map, and to read them afterwards, when I use JDK1.8 I get a very low number of inserts per second.
for (i = 0; i <= nrOfCycles; i++) {
m["key" + i] = "value" + i;
}
and afterwards
var x;
for (i = 0; i <= nrOfCycles; i++) {
x = m["key" + i];
}
Some results (all WARM) for comparison:
JDK1.8 (Nashorn?) -> put is very slow, get is fast
PUT 100000 times took 6955 milliseconds. That's 14378 per second, and 0.06955 ms per event.
GET 100000 times took 13 milliseconds. That's 7692307 per second, and 0.00013 ms per event.
JDK1.7 (Rhino?) -> everything is 'not so fast' but put is faster than nashorn
PUT 100000 times took 606 milliseconds. That's 165016 per second, and 0.00606 ms per event.
GET 100000 times took 481 milliseconds. That's 207900 per second, and 0.00481 ms per event.
OpenJDK7 (?) -> more balanced results
PUT 100000 times took 312 milliseconds. That's 320512 per second, and 0.00312 ms per event.
GET 100000 times took 133 milliseconds. That's 751879 per second, and 0.00133 ms per event.
NodeJS -> for comparison
PUT 1000000 times took 1321 milliseconds. That's 757002 per second, and 0.001321 ms per event.
GET 1000000 times took 121 milliseconds. That's 8264462 per second, and 0.000121 ms per event.
JUSTIFICATION :
The difference with other javascript engines seems way too big to be considered 'normal'
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Results closer to the other implementations, and faster than Rhino, since Nashorn is written to improve the performance of Rhino.
---------- BEGIN SOURCE ----------
//measure the time it takes to execute this javascript
for (i = 0; i <= nrOfCycles; i++) {
m["key" + i] = "value" + i;
}
//and measure the time it takes to execute this javascript
var x;
for (i = 0; i <= nrOfCycles; i++) {
x = m["key" + i];
}
---------- END SOURCE ----------
For some reason inserting items by key in a javascript object is a lot slower on Nashorn than in other javascript engines.
When measuring the time it takes to add items to the map, and to read them afterwards, when I use JDK1.8 I get a very low number of inserts per second.
for (i = 0; i <= nrOfCycles; i++) {
m["key" + i] = "value" + i;
}
and afterwards
var x;
for (i = 0; i <= nrOfCycles; i++) {
x = m["key" + i];
}
Some results (all WARM) for comparison:
JDK1.8 (Nashorn?) -> put is very slow, get is fast
PUT 100000 times took 6955 milliseconds. That's 14378 per second, and 0.06955 ms per event.
GET 100000 times took 13 milliseconds. That's 7692307 per second, and 0.00013 ms per event.
JDK1.7 (Rhino?) -> everything is 'not so fast' but put is faster than nashorn
PUT 100000 times took 606 milliseconds. That's 165016 per second, and 0.00606 ms per event.
GET 100000 times took 481 milliseconds. That's 207900 per second, and 0.00481 ms per event.
OpenJDK7 (?) -> more balanced results
PUT 100000 times took 312 milliseconds. That's 320512 per second, and 0.00312 ms per event.
GET 100000 times took 133 milliseconds. That's 751879 per second, and 0.00133 ms per event.
NodeJS -> for comparison
PUT 1000000 times took 1321 milliseconds. That's 757002 per second, and 0.001321 ms per event.
GET 1000000 times took 121 milliseconds. That's 8264462 per second, and 0.000121 ms per event.
JUSTIFICATION :
The difference with other javascript engines seems way too big to be considered 'normal'
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Results closer to the other implementations, and faster than Rhino, since Nashorn is written to improve the performance of Rhino.
---------- BEGIN SOURCE ----------
//measure the time it takes to execute this javascript
for (i = 0; i <= nrOfCycles; i++) {
m["key" + i] = "value" + i;
}
//and measure the time it takes to execute this javascript
var x;
for (i = 0; i <= nrOfCycles; i++) {
x = m["key" + i];
}
---------- END SOURCE ----------
- relates to
-
JDK-8012306 Check if we can avoid map evolution for global object
- Closed