The various scripting test elements were originally added as a way for people to prototype code easily.
There was no expectation that they would be used in production testing; it was thought that people would convert them to Java if they proved useful. Scripting languages have improved in performance since then, so it starts to make sense to use them more. However, that must not be at the expense of the ability to use them for prototyping. By all means, let's improve the performance, but this needs to be done in a compatible way. On 29 August 2015 at 23:31, Vladimir Sitnikov <sitnikov.vladi...@gmail.com> wrote: >>This way, you could say that behaviour seems awkward ( for now I share your > view). > > It makes sense. > >> you also mentionned nashhorn , do you mean that you used jmeter with it ? > > I do not use jsr223 often. > This thread appeared when I was trying to benchmark several JSR223 > engines and realized JMeter penalizes Nashorn and other engines that > take time to initialize global scope. > >>Javascript performances are awful compared to groovy, did you make some > comparison ? > > I do not have numbers on the top of my head. > > Nashorn is way faster than Rhino. > For instance, it performs comparable to V8 (Chrome's engine) in "react > render" benchmark: > https://github.com/maximenajim/java-vs-node-react-rendering-microbenchmark > > Vladimir
