Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Server-Side I/O Performance: Node vs. PHP vs. Java vs. Go

toptal.com

Post reply on HN
Print view View original

31–40 of 59 posts

Re: Server-Side I/O Performance: Node vs. PHP vs. Java vs. Go

#31

Post by issaria »

TheDong wrote: post #4
callesgg wrote: post #2

Line for line Go will be faster it is compiled. It is the only thing that matters line for line.

No, it's not the only thing that matters. Java's compiled too and was included here, but Go still beat it out. It's likely that C or Rust or C++ would be much faster than Java or Go since they have large runtime overheads; it turns out having a runtime and how heavy it is matter too, not just if it's compiled. There are also cases where non-compiled languages can beat out compiled ones. For example, lua with LuaJIT i…

Java is compile to bytecode which is then interpreted by a virtual machine, it's not compiled to native code, that's why you cannot distribute Java programs as executable like go.

Re: Server-Side I/O Performance: Node vs. PHP vs. Java vs. Go

#32

Post by OutsmartDan »

mtgx wrote: post #11

I visited the post fully expecting the author would benchmark the latest PHP 7.2. To my surprise, he wasn't even benchmarking 7.0, but the old 5.6. I can't take this test seriously.

In terms of the article, pretty graphs and good explanation at first but extremely flawed at running the actual test against these technologies. Wouldn't recommend.

Re: Server-Side I/O Performance: Node vs. PHP vs. Java vs. Go

#33

Post by frugalmail »

He's using the slowest and oldest framework on Java which still is preferable to use if you want things easy to read and maintain. But if you're going for raw I/O performance and already taking the readability and maintenance challenges with the other platforms, then he really should be using Netty, Vert.x or Akka for Java.

Re: Server-Side I/O Performance: Node vs. PHP vs. Java vs. Go

#34

Post by steveklabnik »

bogomipz wrote: post #12
steveklabnik wrote: post #7

Earlier quoted context omitted.

https://nikhilm.github.io/uvbook/filesystem.html > The libuv filesystem operations are different from socket operations. Socket operations use the non-blocking operations provided by the operating system. Filesystem operations use blocking functions internally, but invoke these functions in a thread pool and notify watchers registered with the event loop when application interaction is required.

I'm not familiar with libuv but is there a dedicated "watcher" thread in a thread pool that the kernel wakes up when when the disk driver has completed that I/O that it was sleeping on? If so is there a dedicated "watcher" thread for each non-blocking I/O request handled by libuv?

I’m not familiar at that level.

Re: Server-Side I/O Performance: Node vs. PHP vs. Java vs. Go

#36

Post by frugalmail »

didibus wrote: post #30
pjmlp wrote: post #17

So he acknowledges that has not benchmarked the best options for Java and then selects Go as a winner, what a joke.

Same with Php, using really old versions of it. This is a waste of time article, nothing is learned from it appart the bias of the author.

Ummmm when you care about I/O performance and your building anything of substance (something more than what nginx can do on it's own) why would you choose PHP? The security, fragility and un-maintainability alone are enough reasons to avoid it.

Re: Server-Side I/O Performance: Node vs. PHP vs. Java vs. Go

#39

Post by randomdata »

pjmlp wrote: post #17

So he acknowledges that has not benchmarked the best options for Java and then selects Go as a winner, what a joke.

Reminds me of a "real world" web language shootout I once read, which included accessing a database populated with a large dataset.

The author used a query along the lines of:

    SELECT * FROM table ORDER BY RAND() LIMIT 1
Except for the language they wanted to win, which was basically written like:

    SELECT * FROM table WHERE id = RAND()
Which, of course, resulted in it their favorite being the clear winner.
Post reply on HN