Ruby slow?

ruby-talk
1

Yes, I was being sarcastic :wink: My point was that, if you look at *all* the
results from Doug's "shootout", you'll find that Ruby outperforms some
languages on some tests, and underperforms those same languages on other
tests. You shouldn't put too much stock in the results for one isolated
benchmark.

Having said that, I don't know why Ruby performs *so* badly on this
particular test (the producer-consumer one). I tried with both Ruby 1.6.8
and Ruby 1.7.3 and got comparable results, so (to answer one of your
questions) Ruby 1.7 doesn't improve the results for this particular test.

···

On Fri, 13 Dec 2002 15:45:39 -0700, "Garriss, Michael" <Michael.Garriss@abacus-direct.com> wrote :

true....still not too reassuring

2

yes, ruby is often slower than other languages, but that is simply the price
one pays for a more advanced pure OO dynamically typed language like ruby.
indeed, ruby is also memory intensive from what i understand. but surely
there’s room for improvment on both counts. i think that’s am important focus
for future versions too.

3

Tom Sawyer transami@transami.net writes:

yes, ruby is often slower than other languages, but that is simply
the price one pays for a more advanced pure OO dynamically typed
language like ruby

Slowness is an implementation issue, not to be confused with the
language that is implemented.

indeed, ruby is also memory intensive from what i understand.

Ruby’s memory consumption is modest. As long as you do not keep
unnecessary references, it will stay modest. Please refer to

but surely there’s room for improvment on both counts. i think
that’s am important focus for future versions too.

Such is also my hope that Matz&co. will keep improving the
implementation (and of course, the language)

YS.

4

Slowness is an implementation issue, not to be confused with the
language that is implemented.

only to a point. the implementation of a macro-assemblier will without
question execute faster than, say, a prolog implementation, no matter how
much one tries to make it otherwise.

this is mainly a matter of underlying hardware, and how far one is abstracting
away from the silicon.

a hardwired Ruby CPU anyone? :slight_smile:

Ruby’s memory consumption is modest. As long as you do not keep
unnecessary references, it will stay modest. Please refer to
http://www.rubygarden.org/ruby?GCAndMemoryManagement

thanks, i will.

but surely there’s room for improvment on both counts. i think
that’s am important focus for future versions too.

Such is also my hope that Matz&co. will keep improving the
implementation (and of course, the language)

indeed i had hoped 1.8 would be much faster. but it dosen’t sound like it will
be. perhaps 2.0 then.

-transami

···

On Friday 13 December 2002 11:13 pm, Yohanes Santoso wrote:

5

Hello Yohanes,

Saturday, December 14, 2002, 9:13:01 AM, you wrote:

Slowness is an implementation issue, not to be confused with the
language that is implemented.

really?

···

–
Best regards,
Bulat mailto:bulatz@integ.ru

6

Tom Sawyer transami@transami.net writes:

Such is also my hope that Matz&co. will keep improving the
implementation (and of course, the language)

indeed i had hoped 1.8 would be much faster. but it dosen’t sound
like it will be. perhaps 2.0 then.

Ruby 1.8 will be faster in many areas (1.7 already is).

Many successive String#<< calls are faster, because the string
size is grown more aggressively.

IO is faster, especially with the native Windows version of Ruby.

IO and String operations make up the bulk of Ruby programs, while
Threads are not critical to many scripts.

About 6 months ago I ran a few of the “Language Shootout” tests with
ruby 1.7 and many had improved.

···

On Friday 13 December 2002 11:13 pm, Yohanes Santoso wrote:

7

Really. I’ve seen C/C++ programs which perform abominably because of
(1) poor implementation (gcc/g++ are among the slowest
implementations available for any given platform) and (2) poor use
of the language’s facilities.

I’ve also seen PL/SQL programs (often considered a “slow” language)
which rival or best well-written C/C++ programs in performance for
particular tasks because it is better suited to the nature of the
tasks in question.

-austin
– Austin Ziegler, austin@halostatue.ca on 2002.12.15 at 10.28.12

···

On Sun, 15 Dec 2002 15:24:25 +0900, Bulat Ziganshin wrote:

Saturday, December 14, 2002, 9:13:01 AM, you wrote:

Slowness is an implementation issue, not to be confused with
the language that is implemented.
really?

8

Hello Austin,

Sunday, December 15, 2002, 6:32:29 PM, you wrote:

Slowness is an implementation issue, not to be confused with
the language that is implemented.
really?

Really. I’ve seen C/C++ programs which perform abominably because of
(1) poor implementation (gcc/g++ are among the slowest
implementations available for any given platform)

really? :slight_smile:

and (2) poor use of the language’s facilities.

please don’t change the theme

I’ve also seen PL/SQL programs (often considered a “slow” language)
which rival or best well-written C/C++ programs in performance for
particular tasks because it is better suited to the nature of the
^^^^^^^^^^^^^^^^ ditto - don’t switch to another theme

···

tasks in question.

–
Best regards,
Bulat mailto:bulatz@integ.ru

9

Hello Austin,
Sunday, December 15, 2002, 6:32:29 PM, you wrote:

Slowness is an implementation issue, not to be confused with
the language that is implemented.
really?
Really. I’ve seen C/C++ programs which perform abominably
because of (1) poor implementation (gcc/g++ are among the
slowest implementations available for any given platform)
really? :slight_smile:

Really. On Windows, gcc/g++ are slower than any other compiler
available; this is also true on Solaris and HP-UX. IIRC, for Linux,
gcc/g++ are also slower than Kylix/C++ and the Intel C++ compiler.

and (2) poor use of the language’s facilities.
please don’t change the theme

This isn’t changing the theme. There are many ways to do things in
almost all languages, but not all of them will be efficient. This
was illustrated here recently by the tweaking of some NArray code to
use the facilities offered by the NArray extension itself, resulting
in a significant performance boost.

I’ve also seen PL/SQL programs (often considered a “slow”
language) which rival or best well-written C/C++ programs in
performance for particular tasks because it is better suited
^^^^^^^^^^^^^^^^ ditto - don’t switch to
another theme
to the nature of the tasks in question.

Again, this isn’t a change of theme. To use PL/SQL as an example,
the language is a general purpose programming language. Like Ruby
and Perl, it has one implementation (I am discounting JRuby for now,
as it doesn’t seem to be quite feature-complete, although it may
be usable.) However, for numeric tasks, PL/SQL isn’t the language
you’re going to want to use – the implementation isn’t tuned to
that, although nothing in the language prevents an implementation
from being “good” at numeric computation (it’s an Ada derivative).
With database-oriented data manipulation tasks, however, PL/SQL will
outperform C/C++ in most cases.

Yes, sometimes language features will be slow regardless of the
implementation; but before you claim that something is slow because
of a language feature, you need to make sure that (1) you have used
the optimal implementation within the language, and (2) that it
isn’t simply a performance problem with the implementation itself.
(2) is easier if you have multiple implementations available.

-austin
– Austin Ziegler, austin@halostatue.ca on 2002.12.16 at 07.45.56

···

On Mon, 16 Dec 2002 15:11:17 +0900, Bulat Ziganshin wrote: