Live data from Hacker News

Benchmarking Codswallop: Node.js vs. PHP

philsturgeon.co.uk

61–70 of 85 posts

Re: Benchmarking Codswallop: Node.js vs. PHP

#61
post #8

Benchmarking is very hard because even the same language could show different results. For example: for($i = 0; $i vs $count = count($list); for($i = 0; $i Most of the time benchmarks prove how capable a programmer is, not the speed of the language used.

Any decent compile-time optimizer will transform your first snippet into the second one (or better). Some languages preclude that optimization at compile time, but I presume that a JIT would also have little problem performing that optimization. That is, one could argue that a good language is one that lets developers ignore trivial changes like this without hurting performance.

More as a reference for others, this is a fun page that highlights a few interesting optimizations GCC 4.2 is capable of making: http://ridiculousfish.com/blog/posts/will-it-optimize.html Maybe the optimizer can deduce guarantees about a function, but the writers may have just included an optimization for a specific built-in because the unoptimized form is such a common mistake...

Re: Benchmarking Codswallop: Node.js vs. PHP

#62
post #45

Earlier quoted context omitted.

It think the problem is you are feeding into the same loop. There are also probably ways of making the PHP script go faster still. Also, that seems like a bit of a magic flag to add / tune, why is that not the default, and would I have to keep tuning it for each of my apps?

This is already why the author did though; the original benchmark that he replied to used Cheerio vs. phpQuery, but he rationalized that that was a losing battle anyways, and decided to test Cheerio vs. ReactPHP -- which requires a non-standard PHP extension called libevent.

It's not the phpQuery part that was replaced. It's the file_get_contents() call, which does the http get that he moved to the react framework.

Re: Benchmarking Codswallop: Node.js vs. PHP

#63
post #45

Earlier quoted context omitted.

This is already why the author did though; the original benchmark that he replied to used Cheerio vs. phpQuery, but he rationalized that that was a losing battle anyways, and decided to test Cheerio vs. ReactPHP -- which requires a non-standard PHP extension called libevent.

It's not the phpQuery part that was replaced. It's the file_get_contents() call, which does the http get that he moved to the react framework.

So my point stands... he already deviated from what was originally tested in order to favor PHP.

Why would that be acceptable, but not a simple config change for NodeJS?

Re: Benchmarking Codswallop: Node.js vs. PHP

#64
post #55

Earlier quoted context omitted.

I think the only valid point here is your 3rd one. 1. You have to be kidding, right? PHP's popularity is precisely because of this. 2. getcomposer.org 4. json_decode/json_encode have been a part of PHP since PHP 5.2 (2006) 5. That's not a benefit.

No, it's popularity is because it was the simplest a long time ago, and it's supported on lots of virtual boxes by default. Composer is terrible compared to NPM.

Says you :)

And so is PHP. You cannot argue that PHP is not simple, you just can't.

And frankly I like composer, sure it doesn't do C/C++ installation stuff, but PHP doesn't need that. What is does is almost identical to NPM, the only different is one looks different, and the names.

Re: Benchmarking Codswallop: Node.js vs. PHP

#66
post #43
post #28

I'm sick of all of these generic SPEED benchmarks. Let me tell you some BIGGEST & REAL benefits of NodeJS where PHP SUCKS. 1. Takes 1 minute to install on any platform (*nix, windows etc.) 2. A modern Package Manager (NPM) works seamlessly with all platforms. 3. All libraries started from 0 with async baked in from day 0. 4. No need to use any 3rd party JSON serialize/deserialize libs. 5. And above all, its Atwood's…

Not meaning to troll but: 1. apt-get install php5 ? Seriously, that's it. On the other hand, neither Debian stable nor Ubuntu LTS have any usable version of node in their package repository (Debian has nothing, Ubuntu has 0.6) 4. json_decode() ? 5. If Atwood's law ever becomes reality, it will be a consequence, not a source of benefit. (I don't use either Node or PHP as my main language)

Actually Debian testing has : nodejs 0.10.21~dfsg1-1

Re: Benchmarking Codswallop: Node.js vs. PHP

#67

Earlier quoted context omitted.

The new default in master is Infinity. (Also, there's opt-in KeepAlive that actually keeps sockets alive even if there are no pending requests.) The ulimit will prevent you from opening up too many anyway. The HTTP Client is not the correct place to implement job control and queueing with such a low limit by default.

First things first, IsaacSchlueter in the thread, wow :) So, I'm stress testing our company Node app to find where we can go with it's performance. First problem was file descriptor, which I fixed with your "graceful-fs" module. But now, I'm reaching some "invisible" limit that I can't identify. My app doesn't return any error in the log. Does "maxSockets" will help to receive more requests also or is just to make re…

What performance problem with FD? How many requests exactly are you handling per second with what code or processing? Are you sure its not what he just mentioned, ulimit? The docs say client requests so yes its just to make them.

Re: Benchmarking Codswallop: Node.js vs. PHP

#69
post #59
post #32

The "Thoughts" section was the most informative part of the benchmark which underscores the way I, when I was working with PHP, operated. When I started with PHP(2005), the frameworks were terrible, I would cobble together many random coding examples from stuff I found on the web and just make my own Framework up. I don't think PHP from a performance standpoint is any better or worse, but the default examples that yo…

React was originally called Node.PHP or something similar, if I recall correctly!

http://nodephp.org originally

Re: Benchmarking Codswallop: Node.js vs. PHP

#70
post #55

Earlier quoted context omitted.

I think the only valid point here is your 3rd one. 1. You have to be kidding, right? PHP's popularity is precisely because of this. 2. getcomposer.org 4. json_decode/json_encode have been a part of PHP since PHP 5.2 (2006) 5. That's not a benefit.

No, it's popularity is because it was the simplest a long time ago, and it's supported on lots of virtual boxes by default. Composer is terrible compared to NPM.

..and how do you think it got on all of those boxes? That's a chicken/egg argument.

Composer accomplishes the goals of being a "modern package manager that works on all platforms".

Post reply on HN