Rhino performance VS V8

[Greg Bellingham]

I'm currently looking at vert.x as a platform for web services - many of which will be I/O intensive, but plenty of which also be computationally intensive. I am really, really impressed with the the vert.x architecture, especially that the Verticle/Worker+Bus approach lends itself well to scale and performance at load. However one thing is really bothering me - Rhino. You see, while I myself am inclined to write Verticles in Java, the preference within the team will be JS. It seems from some of the benchmarks I've seen that Rhino is a noticeably poorer performer versus V8 (although I remain a benchmark skeptic having been let down before). If I'm looking at services that support C10K traffic, is Rhino a cause for concern or not? Is there an option to use V8 in vert.x perhaps?

[Nicolas Melendez]

We use rhino in the company  i work, sadly not with vert.x, And Yes,  rhino have less performance than V8 of course.

Try to use "compiling" mode in production and  "interpreting" mode in development.

We serve to 250k Daily Active Users with rhino and we have no problem. 

The thing is how you design the architecture.

Integration V8 is a bit complicated because you are not under the JVM anymore.

Nicolás Meléndez

Software Engineer

Twitter: @nfmelendez

Blog: http://blog.melendez.com.ar/

Github: https://github.com/nfmelendez

Linkedin: http://ar.linkedin.com/in/nicolasmelendez

Sent with Sparrow

On Thursday, June 27, 2013 at 2:09 PM, Greg Bellingham wrote:

I'm currently looking at vert.x as a platform for web services - many of which will be I/O intensive, but plenty of which also be computationally intensive. I am really, really impressed with the the vert.x architecture, especially that the Verticle/Worker+Bus approach lends itself well to scale and performance at load. However one thing is really bothering me - Rhino. You see, while I myself am inclined to write Verticles in Java, the preference within the team will be JS. It seems from some of the benchmarks I've seen that Rhino is a noticeably poorer performer versus V8 (although I remain a benchmark skeptic having been let down before). If I'm looking at services that support C10K traffic, is Rhino a cause for concern or not? Is there an option to use V8 in vert.x perhaps?

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Greg Bellingham]

Much obliged, Nicolas. I'm grateful for the real-world numbers you provided. Most of the time, the performance debate between Node and vert.x is a petty flame war with diminishing objectivity :-)

I agree about the V8 integration complexity, but I thought I'd raise the question anyway. I am frequently surprised about the extent to which open source devs will innovate (I cite Tim Fox and Ryan Dahl as a prime examples!).

[Norman Maurer]

Just as a side note I hope we will have a lang impl using dynjs at some point 

[Nicolas Melendez]

yeah, also there is the project Nashorn, that will be available in java8: http://en.wikipedia.org/wiki/Nashorn_(JavaScript_engine)

Rhino needs a complete rewrite "they" think… seems that new problems are better the old ones :)

But… they say that it will have much more performance than rhino.

That would be another option.

Nicolás Meléndez

Software Engineer

Twitter: @nfmelendez

Blog: http://blog.melendez.com.ar/

Github: https://github.com/nfmelendez

Linkedin: http://ar.linkedin.com/in/nicolasmelendez

Sent with Sparrow

On Thursday, June 27, 2013 at 2:52 PM, Norman Maurer wrote:

dynjs

[Tim Fox]

For many applications you'll find that an application written using
Vert.x + Rhino is considerably *faster* than an application using
Node.js with V8.

Why is this?

It's because in many (most) applications most of the time is not spent
executing your JavaScript code it's spent in the framework code doing
the actual network IO and other processing. In the case of Vert.x that
means most of the CPU cycles are spent executing well optimised Java
code (much of it in Netty). That's how we can be (sometimes much) faster
than the equivalent Node.js application.

On the other hand, if your application spends most of its time doing
number crunching inside your JS code itself, then you might find the
Node.js is faster. It completely depends on your application.

But the reality is... for most people Vert.x with Rhino is still
*damned* fast. I can have JS applications sending 100s of thousands of
messages per second on the event bus quite happily, and I don't know
many people who need that level of performance, and even if they do..
buy a faster server, more memory, better disks. Usually that will be a
lot cheaper than making the wrong choice of development platform.

On 27/06/13 18:43, Greg Bellingham wrote:
> Much obliged, Nicolas. I'm grateful for the real-world numbers you
> provided. Most of the time, the performance debate between Node and vert.x
> is a petty flame war with diminishing objectivity :-)
> I agree about the V8 integration complexity, but I thought I'd raise the
> question anyway. I am frequently surprised about the extent to which open
> source devs will innovate (I cite Tim Fox and Ryan Dahl as a prime
> examples!).
>
> On Thursday, June 27, 2013 10:20:17 AM UTC-7, nicolas melendez wrote:
>> We use rhino in the company i work, sadly not with vert.x, And Yes,
>> rhino have less performance than V8 of course.
>> Try to use "compiling" mode in production and "interpreting" mode in
>> development.
>>
>> We serve to 250k Daily Active Users with rhino and we have no problem.
>> The thing is how you design the architecture.
>>
>> Integration V8 is a bit complicated because you are not under the JVM
>> anymore.
>>

>> *Nicol�s Mel�ndez*
>> *Software Engineer*

>>
>> Twitter: @nfmelendez
>> Blog: http://blog.melendez.com.ar/
>> Github: https://github.com/nfmelendez
>> Linkedin: http://ar.linkedin.com/in/nicolasmelendez

>> *
>> *
>>
>>
>> Sent with Sparrow <http://www.sparrowmailapp.com/?sig>

>>
>> On Thursday, June 27, 2013 at 2:09 PM, Greg Bellingham wrote:
>>
>> I'm currently looking at vert.x as a platform for web services - many of
>> which will be I/O intensive, but plenty of which also be computationally
>> intensive. I am really, really impressed with the the vert.x architecture,
>> especially that the Verticle/Worker+Bus approach lends itself well to scale
>> and performance at load. However one thing is really bothering me - Rhino.
>> You see, while I myself am inclined to write Verticles in Java, the
>> preference within the team will be JS. It seems from some of the benchmarks
>> I've seen that Rhino is a noticeably poorer performer versus V8 (although I
>> remain a benchmark skeptic having been let down before). If I'm looking at
>> services that support C10K traffic, is Rhino a cause for concern or not? Is
>> there an option to use V8 in vert.x perhaps?
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "vert.x" group.
>> To unsubscribe from this group and stop receiving emails from it, send an

>> email to vertx+un...@googlegroups.com <javascript:>.

[Greg Bellingham]

Invaluable information everyone - thank you very much indeed. I think this has made up my mind in favor of vert.x. Tim - I may contact you regarding your "who's using vert.x?" list at a later date :-)