jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: Nashorm Javascript engine
Date Mon, 14 Sep 2015 14:51:33 GMT
On 14 September 2015 at 12:58, Vladimir Sitnikov
<sitnikov.vladimir@gmail.com> wrote:
>> Apart from compatibility issues [1]
>
> I do know there are compatibility issues, however is is rather smooth
> if you are creating a new script.
> I do know what "backward compatibility" is.

It means that existing Javascript scripts will run without needing to
be amended.

>> I got the speed info from the diagram in the link from the Bugzilla:
>> http://ariya.ofilabs.com/2014/03/nashorn-the-new-rhino-on-the-block.html
>
> This benchmark makes very little sense. Proper benchmarking should
> involve jmh [1]

I quoted the URL because it was used in justifying Nashorn over Rhino.
However the page clearly shows that Nashorn is not always faster.

Given that
- Nashorn is not always faster
- it may have compatibility issues
it is clearly NOT OK to change JMeter without prior discussion of the issues.

We may well decide that the advantages outweigh the disadvantages, but
that discussion needs to occur and for agreement to be reached.

>>Nashorn is NOT always faster than Rhino
>
> Well, what if it is faster in 99.9% cases?
> I mean that we never find a library that will be always faster than
> Rhino. There always be at lease a case or two where Rhino wins.
> Does that mean we have to live with Rhino forever?

No, but the decision needs to take these facts into consideration.

> [1] http://openjdk.java.net/projects/code-tools/jmh/
>
> Vladimir

Mime
View raw message