[dreamdu5t]

This is all great but... why?

[jacques_chester]

Because:

1. the JVM is an open, stable, mature, fast platform for server applications.

2. Facebook are not moving off PHP any time soon.

3. For stuff outside its written-in-C standard lib, PHP is quite slow. PHP's garbage collection, JITting etc is nowhere near as advanced as the JVM's.

4. Since porting dynamic languages to the JVM is a well-worn pathway, why not try porting PHP and see how it performs?

If Facebook can reduce their CPU and RAM requirements by just 10%, it pays for itself many times over vs the stock PHP runtime. And based on what I've seen with JRuby (going from 50Mb MRI runtimes down to 2.5Mb runtimes that are 3-10x faster) that's entirely reasonable.

[dataminer]

What kind of computations were you doing on MRI which resulted in such performance boost by switching to JRuby? I have tried Rails under JRuby many times, the performance is the same as 1.9.3 and memory consumption usually higher.

[jacques_chester]

Redmine. Runs faster and smaller per instance of the application.

[jacques_chester]

Looking at my post again, I guess I didn't do a very good job.

I didn't mean 2.5Mb per copy of the JVM. I meant per runtime within the JVM. These are run as threads, rather than processes.

So we're really comparing

    n instances of MRI * 50Mb

vs

    1 JVM + (n * 2.5Mb)

Where the cost of the JVM itself is amortised over the application instances.

Sorry, what I said originally is easily misleading.

[jeremiep]

My reaction exactly. I have great respect for the JVM, but PHP could simply be replaced by JavaScript for example.

It seems easier to me to port PHP to Rhino or node.js than to bring PHP to the JVM. Especially considering CoffeeScript, PHP just can't keep up.

[mh-]

was this post just written with a JavaScript-buzzword generator?

[erichocean]

Yes.js