jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <philippe.moua...@gmail.com>
Subject Re: Nashorm Javascript engine
Date Tue, 15 Sep 2015 19:40:03 GMT
Hello,
@Other team members, what's your opinion on this ?

Thanks
Regards

On Tue, Sep 15, 2015 at 7:38 AM, Philippe Mouawad <
philippe.mouawad@gmail.com> wrote:

>
>
> On Tuesday, September 15, 2015, sebb <sebbaz@gmail.com> wrote:
>
>> 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.
>>
>>  so what do you propose ?
>
> > Complexity of such script would be very low.
>>
>> Probably, but that does not mean the script cannot break.
>>
>>
> so you want the statu quo ?
>
>
>> > 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.
>>
>>
> I don't know what to say. I tend to think we have very low risk to have
> issues here, we mention the incompatible change so user check their script
> once they upgrade.
> And if any regression they have the option to debug or revert to old
> behaviour.
> Backward compatibility is rather well managed here. It should not be a
> stopper for any change in JMeter.
>
> New scripts are built on nashorn and that 's it.
>
> You think something else, why would I have to prove that it will not break
> , and not you prove that it will?
>
>
>
> In my opinion unless you have a big explicit case where it breaks I see no
> reason not to move forward.
>
>
>
>
>> > 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.
>>
>>
> what do you propose ?
>
>
>> >
>> >> >> 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.
>
>
> the migration guide does not show big regression risks.
>
>
>>
>> > 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.
>>
>>  As a standard user, would you choose javascript (very well known) or
> rhino(more specialized ) ?
> I think most users choose javascript.
> Seeing lot of questions on JMeter at stackoverflow , they frequently
> mention js or javascript.
>
>
> However if they selected "javascript" or "js" then they will get the
>> default JS engine.
>
> And in this case there are chances to break.
>
>
>>
>> > 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.
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>
>
>
>


-- 
Cordialement.
Philippe Mouawad.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message