On Mon, Sep 14, 2015 at 4:51 PM, sebb <[email protected]> wrote: > On 14 September 2015 at 12:58, Vladimir Sitnikov > <[email protected]> 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 ? Complexity of such script would be very low. I doubt Rhino and Nashorn would differ in the way of interpreting those scripts. 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.. > >> 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. 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. 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. In my opinion there are much bigger chances to break things here as the script has chances to be bigger. > > 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.
