
Perl, Python, Ruby, PHP, C, C++, Lua, tcl, JavaScript and Java comparison - bane
http://raid6.com.au/~onlyjob/posts/arena/
======
NAFV_P
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.

------
facorreia
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.

~~~
deluvas
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.

~~~
facorreia
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.

~~~
na85
Performance matters much less on the web.

~~~
Fishkins
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.

------
bane
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.

------
StefanKarpinski
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.

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

------
AnimalMuppet
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?

------
erobbins
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

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

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

gcj is dead.

