jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: JSR223 elements performance
Date Sat, 29 Aug 2015 22:40:31 GMT
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.vladimir@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

Mime
View raw message