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 22:42:20 GMT
On 14 September 2015 at 21:28, Philippe Mouawad
<philippe.mouawad@gmail.com> wrote:
> On Mon, Sep 14, 2015 at 4:51 PM, sebb <sebbaz@gmail.com> wrote:
>
>> 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.
>>
>
> What is the probability to break a Javascript code in IF Controller ?

Depends on what the incompatible changes are.

> Complexity of such script would be very low.

Probably, but that does not mean the script cannot break.

> I doubt  Rhino and Nashorn would differ in the way of interpreting those
> scripts.

That may be true but is just guesswork without more evidence.

> Based on this:
> https://wiki.openjdk.java.net/display/Nashorn/Rhino+Migration+Guide
>
> Maybe the biggest risk is in replace, but I am not sure..

This needs to be established.

>
>> >> 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
>>
> Can you point to a particular case where it is not and that users would
> meet in the JMeter scope ?
>
>
>> - it may have compatibility issues
>>
> as long as we propose a way to select rhino and given that chances of
> having regressions is very low, is it really a big risk.

We don't yet what the chance of regressions is.

> In the benchmark I made using 2 IfControllers, there is a 50% increase in
> throughput.
>
>
> it is clearly NOT OK to change JMeter without prior discussion of the
>> issues.
>>
>
>
> I suppose we are discussing it here.

Yes, we are now.

> One side note.
> Whenever a user migrates to Java8, the Javascript engine used by JSR223
> Test Elements is switched without any other notice from RHINO to NASHORN.

That's not quite true.

If the user originally selected "rhino" then the test plan will fail
because "rhino" has been dropped as a valid engine.

However if they selected "javascript" or "js" then they will get the
default JS engine.

> In my opinion there are much bigger chances to break things  here as the
> script has chances to be bigger.

It is likely that such scripts will be bigger, however the user will
get a clear warning if they selected Rhino specifically.

>
>>
>> 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
>>
>
>
>
> --
> Cordialement.
> Philippe Mouawad.

Mime
View raw message