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

http://raid6.com.au/~onlyjob/posts/arena/

by bane • 12 years ago

18 20 12 years ago

raid6.com.au

facorreia2• 12 years ago

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• 12 years ago

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.

facorreia2• 12 years ago

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.

peterwwillis2• 12 years ago

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.

NAFV_P2• 12 years ago

Perl is strictly speaking, compiled.

jgriego• 12 years ago

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

nine_k• 12 years ago

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.

stormcrowsx• 12 years ago

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

bane2• 12 years ago

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.

bane2• 12 years ago

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.

AnimalMuppet• 12 years ago

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?

mark_l_watson• 12 years ago

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

NAFV_P2• 12 years ago

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.

pjmlp• 12 years ago

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

gcj is dead.

detrino• 12 years ago

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

erobbins• 12 years ago

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

StefanKarpinski• 12 years ago

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.

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

Related Stories