Re: ruby as slow scripting language vs java?

[Dmitry Borodaenko]

On Mon, Aug 29, 2005 at 10:56:35PM +0200, boud wrote:
> ruby is a scripting language, not a compiled language, and hence runs
> much slower than a language like java.

This is a subject of much heated debate in many communities, including
Ruby community, scripting language community, and computer language
community as a whole.

Formally, this statement is false on several accounts, most obvious
being that 1) you can only compare applications and not languages, 2)
not all Ruby applications are slower that similar Java applications, 3)
speed difference has very little to do with scripting vs. compiled
languages.

Not to mention the argument that no so long ago was used in defence of
Java vs. C++: when application is fast _enough_, it's development time
that matters, not run time.

> According to this analysis:
> 
> http://shootout.alioth.debian.org/benchmark.php?test=all&lang=java&lang2=ruby&sort=fullcpu
> 
> java runs many codes anywhere from 50 to 200 times faster than ruby,
> though it also uses typically up to 5 times as much memory.

The Shootout is well-known for being completely unscientific and having
~0% intersection with real life. It says so on its front page: "few
dozen flawed benchmarks", "we measure particular programs".

For another, also unscientific, but more real-life comparison, check
this:

http://www.relevancellc.com/blogs/?p=31

The interesting fact is that the author is a Java expert and has written
a book on the Spring framework, which makes it even more astonishing
that his first try with Ruby seriously outperforms his Java/Spring
application.

> Would there be any sense to think of preparing a java version (but
> designed to run on the free versions of jvm's/jre's, not the sun
> versions) ?

No.

> Personally, i don't have any experience programming in either of these
> languages. (i've started in C, in the past i wrote in fortran.)

You should try both. This will make you understand why I say strong "No"
to Java :)

> Could it be that none of these tests are for the sort of operations
> which are slowest for a CMS, e.g. string operations? e.g. sum-file
> seems to be a program which operates and strings, and it is only about
> 10 times slower in ruby than java, according to the table.

The Shootout can't be helped, just forget about it. The Spring vs. Rails
example shows perfectly that most performance gains do not come from the
language of implementation (or implementation of the language :), but
rather from coding practices and specific optimizations. In the case of
Samizdat, I had 10x and even 100x performance improvements (in
real-life, not some narrow benchmarks) mostly due to better database
indexing and smarter caching. Last time I checked, about 30-70% of CPU
time during stress test was spent in PostgreSQL, not in Ruby
interpreter.

(...)
> i have to admit that except for servers with tight memory constraints,
> this is a rather discouraging argument against samizdat :(.  Please
> correct me if i'm wrong...

If I haven't convinced you yet, here is another argument in favor of
Samizdat: current snapshot of Samizdat contains ~4800 raw source lines
of *.rb code (counted with wc -l, including empty lines and comments).
Same count for DadaIMC version that I have gives ~38000, for SF-Active
it's ~25000, I can't get a hold of a source code snapshot for Mir, last
time I've seen it the tarball was couple of times bigger than SF-Active.

And Samizdat code is clean and well commented, you can't say that it's
short because it's unreadable. And complexity of code grows as an
exponent of its size. And Samizdat has more that 1/5th of features of
these two engines (more like somewhere between 1/3 and 2/3 depending how
you count).

Does this help to decide which code base you'd prefer to deal with as a
developer? ;-)

-- 
Dmitry Borodaenko