Perl, Python, Ruby, PHP, C, C++, Lua, tcl, JavaScript and Java comparison | Hacker News Reader

Perl, Python, Ruby, PHP, C, C++, Lua, tcl, JavaScript and Java comparison

raid6.com.au

18 pointsbane20 comments

I think I noticed a serious flaw, have a peek at the includes in the C source ....

  #include <time.h>

The program is using its own standard library to time itself, and I presume this applies to the other specimen languages. In order for this to be a fair test, the timing method utilised should be the same for all languages in question.

I can testify from my own experience that time() in time.h is highly unreliable, my uttering of "naut mississippi", "one mississippi", "two mississippi" was far more precise.

Of course the above does not apply to memory usage.

Results in Java are not representative because they use the String type for concatenation tests instead of the recommended practice of using a StringBuilder for extensive concatenations.

Exactly. The author uses string concatenation in tight loops in Java without blinking, let alone a lengthy comment explaining such a decision. After this, I fail to trust any of his results.

Maybe the problem with Java is that the obvious implementation isn't the best one.

It's just the same situation for Lua; they're using repeated concatenation instead of a table and `table.concat`.

Well, wouldn't it make more sense for the compiler or VM to handle this kind of optimization under the hood? It seems needless that the direct way of doing it is the slower and "unless you just know" to do it this other round about way you'd never arrive at this.

Still I'd love to see the same benchmarks done with more idiomatic code.

I'm not buying these tests, either. Since when are scripting languages faster at string manipulation (and generally) than compiled languages?

Will somebody explain to me what's going on? Maybe I'm missing something.

Perl is not necessarily faster than C at all string manipulation, but it does have some handy features that makes short work of more complicated functionality. See here: http://www.perl.com/pub/2001/06/27/ctoperl.html

Sometimes Perl does things more uniformly across different systems than would be done on a single system with a different language like C. For example, this is Perl's malloc implementation: http://perl5.git.perl.org/perl.git/blob/7742aa6637b99424497e...

Depending on what you are doing, Perl may have a more efficient way of tackling the problem. This isn't to say you couldn't do it in that exact same way in a different language and find a faster result; it's just that Perl already does things efficiently, so you don't have to spend time tuning algorithms.

It's just a misguided benchmark. It contains statements such as "Java applications cannot match a fraction of other language's performance." That's in contrast with the experience of companies such as Twitter, LinkedIn and Yammer.

Performance matters much less on the web.

The point is, at least in the case of Twitter, they switched from Ruby to Java/Scala because they needed performance. Before that you could have been forgiven for thinking twitter was just a static page displaying the fail whale.

s?on the web?when you can scale your infrastructure horizontally using asynchronous, connectionless queries distributed across a global network with large peers, layers of caching and a set of uniform standards to interact with client/server applications?g

Perl is strictly speaking, compiled.

I'd like to see a more modern version of this comparison, with more idiomatic versions of the test code. The nice thing is that this research was done in the open so we can see the code used for each language.

These are some jarringly flawed and frustrating comparisons that seem blatantly biased towards concluding that Perl is awesome and Java sucks. However, Perl is really phenomenal for this kind of string processing – amazingly enough, it is actually often faster and more efficient than the C code you would have written. That said, I still only ever use Perl for one-liners and page-long filter scripts these days.

Except for the poorly written examples that do quadratic string concatenation, this is just a benchmark of string searching, everything else is irrelevant.

If I understand correctly, Perl is written in C. That means that it must be possible to write this in C so that it runs at least as fast as Perl does (in the worst case, write a Perl interpreter in C...)

So I suspect that the C code wasn't written as optimally as it could be.

Maybe the point is that a naive implementation in Perl has better performance than a naive implementation in other languages?

this is pretty bad code.

For the C version, just changing strcat(gstr, str); to strcat(&gstr[lngth - str_len], str); cuts the execution time by 1/4 for the longest cases.

original: 471sec 4096kb

changed: 356sec 4096kb

To be fair, shouldn't the Java benchmark program use StringBuilder?

Stop using gcj as native Java compiler in tests, use RoboVM instead, or any other aot compiler for Java.

gcj is dead.

Reply on news.ycombinator.com