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.
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.
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
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.
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.
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.
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'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.
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?
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.
Except for the poorly written examples that do quadratic string concatenation, this is just a benchmark of string searching, everything else is irrelevant.
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.
20 comments
[ 3.2 ms ] story [ 54.9 ms ] threadWill somebody explain to me what's going on? Maybe I'm missing something.
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.
Still I'd love to see the same benchmarks done with more idiomatic code.
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?
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.
gcj is dead.
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