[thebluesky]

Java is slow ... It scalability is a joke. I've worked as a Java contractor at a number of places and what a PERL/PHP/Python solution can get done in 5 boxes, it takes Java 30-40 boxes. This is NOT an exagerration.

Hard to believe this one is still getting wheeled out in 2012. Java is MASSIVELY faster than Perl/Ruby/Python: http://shootout.alioth.debian.org/u64q/benchmark.php?test=al...

I've seen over and over how Java code is at the very least an order of magnitude faster than a solution in a scripting language.

BTW the correct spelling is "exaggeration"

[Roboprog]

Man I dislike the language shootout benchmarks. I'm not a chemist :-(

The DNA complement substitution is close to string processing, but still feels like mostly bit twiddling. Likewise, lot's of numeric fidgeting in those benchmarks.

I want something that does numeric and string conversions; string concatenation; file I/O; network I/O benchmarks. Also, something that could indicate how the strings were encoded, perhaps separate benchmarks for 7 bit ascii vs UTF-8, etc.

[thebluesky]

You'll get similar results for most benchmarks. Languages such as Ruby/Perl/Python are consistently slower than Java. There's no such thing as a perfect benchmark, but I've found the language shootout page to be a pretty accurate reflection of what I've observed in practice.

[Roboprog]

My data says "usually, but not always":

http://roboprogs.com/devel/2009.12.html

I suppose I need to update this on newer machines (e.g. - 6 core AMD box I have now, for starters, instead of an old Pentium-D), and it's certainly possible I FUBARed the Java implementation. If anybody thinks they can clean up the Java, so that the single-threaded performance is better, here it is:

https://github.com/roboprog/mp_bench

I got similar results, albeit with much older versions of Perl and Java, about 10 years ago on sample code I made to index a flat-file in Perl and Java. That code belonged to my then employer, so I don't have it.

[igouy]

>> FUBARed the Java implementation <<

    // deliberately *not* using StringBuffer / StringBuilder,
    // as a real app would have many transient string variables

[Roboprog]

Because I know that every corporate app dev is (NOT) going to write:

   StringBuilder buf = new StringBuilder( s1);

   buf.append( s2);

   String cat = buf.toString();

instead of:

   String cat = s1 + s1;

in their application code. (although I think that is pretty much what the compiler generates on your behalf, anyway)

The loop is in the benchmark so I don't have to write code dealing with many different string values of differing size manually.

[igouy]

Man I dislike people who complain instead of fixing what they don't like :-(

Create the task definitions you want; write the best code you can for those tasks with an interpreted language, a JIT'd language and an aot compiled language; set-up the measurements framework and SCM for open contribution of programs; and then put up a website showing all that stuff and maintain it for the next 5 years.