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.
Benchmarking Codswallop: Node.js vs. PHP
61–70 of 85 posts
Re: Benchmarking Codswallop: Node.js vs. PHP
#62Earlier 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.
Re: Benchmarking Codswallop: Node.js vs. PHP
#63Earlier 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.
Why would that be acceptable, but not a simple config change for NodeJS?
Re: Benchmarking Codswallop: Node.js vs. PHP
#64Earlier 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 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
#65ReactPHP does look great, hope it will be in stable enough state for production usage. Also it seems it's only done by one person?
Re: Benchmarking Codswallop: Node.js vs. PHP
#66I'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)
Re: Benchmarking Codswallop: Node.js vs. PHP
#67Earlier 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…
Re: Benchmarking Codswallop: Node.js vs. PHP
#68Doing async in PHP still feels like strapping a dildo to a horse and calling it an unicorn.
Re: Benchmarking Codswallop: Node.js vs. PHP
#69The "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!
Re: Benchmarking Codswallop: Node.js vs. PHP
#70Earlier 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.
Composer accomplishes the goals of being a "modern package manager that works on all platforms".