4 ms·
This is all great but... why?
by dreamdu5t 14y ago
This is all great but... why?
- jeremiep 14y agoMy 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.
- deleted 14y ago[deleted]
- mh- 14y agowas this post just written with a JavaScript-buzzword generator?
- erichocean 14y agoYes.js
- jacques_chester 14y agoBecause: 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 14y agoWhat 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 14y agoRedmine. Runs faster and smaller per instance of the application.
- jacques_chester 14y agoLooking 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.