Zed and Luis drop the bomb on Ruby's poor performance

ruby-talk
21

Roger Pack wrote:

YARV and Ruby's poor computational performance. Zed said, and I quote:

I?ll be honest right away though and say that Ruby is slow. The Ruby community has been ignoring the huge ?performance? elephant standing in the room and they need to start talking about it so it goes away. Elephants hate being talked about. There are a few efforts to make Ruby faster, but I see a lot less action than is needed to solve the problem. One solution in the works is a real virtual machine called Rite (or YARV depending on who you talk to) which is showing some real promise and seems to be speed competitive with the fastest Java implementations.

Yeah I have come to the sad conclusion that, at least with the 1.8.x world, if speedy execution is your goal you should probably choose another scripting language [python+psycho comes to mind]. Especially when considered in conjunction with rails. There I have mentioned the elephant :slight_smile:
That being said, thankfully 95% of web pages and scripts don't really care about getting hammered, since they never will be. But the other 5% will suffer until this gets figured out. And I'm not volunteering. Hopefully this will improve in the near future. Until then back to my coding of some poorly performing, elegantly written web pages.
-R

Well, Zed's rant *was* published some time ago -- before the 1.9.0 release, I think. I know very little has changed in the MRI performance arena, but "Rite" and "YARV" are the same thing as far as I know and are/is indeed faster at the core than MRI.

As far as Rails is concerned, though, quite a bit of work is available on the web on hacks for tuning it, things to avoid in your Ruby code, etc. I suspect there is more that *isn't* publicly available on tuning Rails.

The way I interpret open source licenses, if you take an open source toolset, squeeze all the major bottlenecks out of it and put it into production in a server, there's no requirement for you to release the source of your hacks as long as you don't attempt to distribute the resulting binaries. :slight_smile:

I've speculated a bit on what I think might happen in my blog.

http://ruby-perspectives.blogspot.com/2008/06/ruby-rails-and-life-on-edge-of-chaos.html

22

I don't think it is Ruby's (or Matz's) vision for Ruby to penetrate
the corporate environment. Keep in mind that unlike Java or C#, Ruby
is not a commercial language, and there isn't really any benefit to
massive corporate uptake of Ruby. For those of us that enjoy the
language it certainly would be nice for our choice to be "validated"
by getting more market share, but in general myself and probably most
other Rubyists don't put much value on corporate use being an
indicator of language popularity.

Still, performance is important, and YARV will be a great improvement
in that area.

Ryan

···

On 5/22/06, Madan Manoharan <madan.manoharan@gmail.com> wrote:

IMO, if Ruby's vision is to penetrate the corporate environment, Ruby
should address its performance issues among other things (e.g. support
for apps -- Ruby on Rails).

23

Madan, can you elaborate on this:
"(e.g. support for apps -- Ruby on Rails)"

thanks

···

On 5/22/06, Madan Manoharan <madan.manoharan@gmail.com> wrote:

On 5/22/06, benjohn@fysh.org <benjohn@fysh.org> wrote:
> I just want to point out why it doesn't (pragmatically) matter to me
> personally atm.
>

Unfortunately, not all of us are in your boat. I really like Ruby, but
if performance improvement is not going to be in Ruby's near future,
my management is not going to buy into Ruby!

In most of the corporate environments I have worked in, many managers
tend to take IT decisions based on 'feelings'; 'speed' is a word that
creates good 'feelings'. So, when the issue of performance is bought
up, Ruby doesn't win (doesn't matter if the application requires it or
not).

IMO, if Ruby's vision is to penetrate the corporate environment, Ruby
should address its performance issues among other things (e.g. support
for apps -- Ruby on Rails).

-Madan.

24

The thing that always stands out to me in these performance discussions is
that people argue that Ruby needs a performance improvement, but there are
rarely any specifics attached to that analysis.

How much of speed improvement? How fast should Ruby be? For what?

I like speed in my applications. It gives me a warm, fuzzy feeling. However
Ruby's speed has never been a problem for me, and I have been using Ruby in
enterprise applications, for at least some definitions of enterprise, for 4
years.

On really very modest hardware it is no problem for me to dynamically generate
web pages for sites/applications fast enough that it could handle _millions_
of hits a day. That is, if I can optimize away the cost of most database
interactions through caching or other mechanisms. Ruby could be 10x faster,
and if I have to make database queries with each request, it's not going to
matter, because Ruby isn't the bottleneck, most of the time.

I do a lot of data/file generation/handling/transformation/transport duties
with Ruby, and Ruby is never the bottleneck.

I do email build/send tasks with Ruby, and Ruby isn't the bottleneck. In
fact, I have a number of years experience in the dynamic, targetted email
business, and my relatively simple Ruby based email build platform is more
powerful, easier to use, and faster than the quite expensive (in developer
hours spent to build/optimize it) Java based system that my last employer
used.

Ruby can be a bottleneck, but for the vast majority of Ruby users and the vast
majority of tasks people use if for, it is not the bottleneck.

It is not an elephant in the living room that everyone is ignoring if the
performance simply isn't a limiting factor. It's an elephant out in the
paddock, where it belongs in those cases. And those cases are the majority
of cases.

Kirk Haines

···

On Monday 22 May 2006 9:25 am, Madan Manoharan wrote:

On 5/22/06, benjohn@fysh.org <benjohn@fysh.org> wrote:
> I just want to point out why it doesn't (pragmatically) matter to me
> personally atm.

Unfortunately, not all of us are in your boat. I really like Ruby, but
if performance improvement is not going to be in Ruby's near future,
my management is not going to buy into Ruby!

25

Personally, I like it just fine when companies make decisions based on
feelings rather than logic. This is just one reason why there is
always room in the market for a new competitor.

Gary Wright

···

On May 22, 2006, at 11:25 AM, Madan Manoharan wrote:

In most of the corporate environments I have worked in, many managers
tend to take IT decisions based on 'feelings'; 'speed' is a word that
creates good 'feelings'. So, when the issue of performance is bought
up, Ruby doesn't win (doesn't matter if the application requires it or
not).

26

The problem is that Zed and Luis make out that performance is something that the whole Ruby community is deliberately ignoring. This is not the case, there are plenty of people who have no issue with the performance of Ruby. The truth is the performance is an issue for Zed and Luis and they are trying to make out that it is not their personal bugbear but some sort of conspiracy so they don't look like whiners. I have never though "damn Ruby's dismal performance, it should be able to do this faster" and I probably never will.

Yes we wouldn't say no to better performance but we (the Ruby community) are not being held back by the current level of performance.

27

you make good points - but let me just throw in my 2 cts:

virtual machines are stupid. java is slow. c++ is slow. python is slow.
ruby is slow. so what. if you want fast you need c or fortan or assembler.
all three are very easy to call from ruby. i use mmap, narray, gsl, ruby/dl,
ruby queue to cluster and other combos to process GB sized images on a routine
basis. people are doing real-time video processing with ruby using a similar
approach. the key to speed is c, not a vm and, if you ask me, that quest is
the white elephant - not ruby's speed. projects like ruby2c, ruby-inline,
ruby/dl, swig - those are the way to speed. putting a vm on top of ruby and
trying to make it fast is like chopping and dropping your mini-van and heading
to the track : you are going to get killed. i think it's right to demand a
specfic need for speed because, if people do, i think it will become apparent
that any vm will have a hard time competing with a little thinking, a lot of
ruby, and a little c via some of the nice projects that let us it. and, if we
stick to gcc, we also get the best portability of any code generator out
there. lastly, this approach is here __now__ - we don't have to wait.

just my thoughts.

-a

···

On Tue, 23 May 2006 cremes.devlist@mac.com wrote:

Not to single you out (though I guess I am) but you are the first one in the thread to write-in with "it's good enough for me because of <insert reasons having nothing to do with computation speed here>."

I think we all know this. Most of us on this list are here because we find the language expressive, clean, fast enough for whatever, yada yada yada.

This thread is *specifically* about getting more computational performance for Ruby. Let's not throw it off track by reiterating all the *other* reasons the language is "good enough" for us.

All that said - I'll crack open a drink to Ruby's performance improving.

Good! Me too!

I just want to point out why it doesn't (pragmatically) matter to me
personally atm.

Oops! Wrong thread! :slight_smile:

cr

--
be kind whenever possible... it is always possible.
- h.h. the 14th dali lama

28

This thread is *specifically* about getting more computational
performance for Ruby. Let's not throw it off track by reiterating all
the *other* reasons the language is "good enough" for us.

How much more? Ruby will never be as fast as hand written assembly
code, well written C, etc. The problem with the performance debate is
premature optimization. When things are too slow, optimize the 5% of
your code that is too slow (after careful profiling to locate that 5%)
-- if necessary as a C extension.

I am all for a fast Ruby, YARV will likely deliver when it is ready.
Even with YARV and a some future JIT compiler, there will be times
when your application is too slow and will require optimization.
Making Ruby faster is not going to help in many cases, you still need
to profile and optimize.

Can Ruby's performance be increased? Yes, but the only "elephant" in
the room is the astral projection of Sir Charles Antony Richard Hoare
muttering that the root of all evil is premature optimization...

pth

29

Hi cr,

You stated that this kind of comment is off the thread topic:

I just want to point out why it doesn't (pragmatically) matter to me
personally atm.

Oops! Wrong thread! :slight_smile:

cr

But when you started the thread one of the questions you asked was:

  "Why aren't we talking about it all the time?"

"it" being the performance issue. If this was not one of the topics you wished to discuss in this thread it would be better not to specifically ask about it.

···

----

I think we aren't talking about it all the time because most of us don't have the expertise to contribute to the design and programming of a Ruby byte-code compiler however I am closely following the progress of YARV.

Here's a concrete example of something I am doing in Ruby that I would like to be faster:

I am using REXML and ruby-spreadsheet to read XML archives of Blackboard courses (an e-learning platform) and to process the forum discussions to produce interesting (at least to the education researchers I work with) statistics of all kinds about the conversations learners have in our on-line courses.

Right now it takes about 30s to process a BB archive and produce the excel report. I am VERY happy programming using the native ruby tools for parsing the BB XML and writing my object representations back out as excel worksheets. These libraries are almost trivial to acquire (gem for the spreadsheet) and to use. However if I was to instead make an interactive application I'd like the process to be sped up by about 10x. I could use the ruby bindings for the C libxml library if I need to but I'd rather stay totally in Ruby. Until Ruby 2.0 is available I am quite happy that if I need the performance I can use a C library to speed up the slow parts.

Something practical: I'll test my relatively simple app with the latest YARV and post here and to the YARV folks my results.

FYI: Downloading and installing YARV: YARV: Yet Another Ruby VM

--
- Stephen Bannasch
  Concord Consortium, http://www.concord.org

30

This is exactly - but *exactly* - the sort of thing that was said
about Java at its onset. Especially in environments where it was
evaluated against a C++ backdrop. And guess what? Eventually, it
didn't matter! Java did get widely adopted because it was a better
language and offered an improved development experience.

In fact IIRC, Java was relatively much slower than Ruby when it
started gaining momentum. Certainly if you consider the computer speed
back then. How many project managers are saying "well, Java would give
us a much faster development process, and with the superior
maintainability we should not only beat everyone else to the market
but also keep ahead of the competition, but let's write the thing in
C++ to save those few extra CPU cycles"?. Now replace C++ with C,
Fortran or Assembly. How much software is written today in Assembly to
truly squeeze the last drops of performance out of the machine? ...
Exactly.

In fact, most of C++ (and I'd arge - any lanauge lower-level than
Ruby, including Java) use is *misuse*. Most developers using C++
today are doing it out of inertia, habit, or at most for legacy
reason. Even without the insanely powerful machines considered "norm"
on our desktop today, C++ development is 99% premature optimization.
And the funny fact is that most of those 99% won't even get the
performance they wasted 50%-90% of their development sweat (and
tears!) upon. Since contrary to popular myth, writing your application
in C++ won't make it magically faster. The developer would have to be
pretty smart for that. And for those 99%, being smart means they would
have been using Java. If they were even smarter, they'd be using Ruby
:stuck_out_tongue:

···

On 5/22/06, Madan Manoharan <madan.manoharan@gmail.com> wrote:

On 5/22/06, benjohn@fysh.org <benjohn@fysh.org> wrote:
...
Unfortunately, not all of us are in your boat. I really like Ruby, but
if performance improvement is not going to be in Ruby's near future,
my management is not going to buy into Ruby!

In most of the corporate environments I have worked in, many managers
tend to take IT decisions based on 'feelings'; 'speed' is a word that
creates good 'feelings'. So, when the issue of performance is bought
up, Ruby doesn't win (doesn't matter if the application requires it or
not).

IMO, if Ruby's vision is to penetrate the corporate environment, Ruby
should address its performance issues among other things (e.g. support
for apps -- Ruby on Rails).

--
-Alder

31

Lisp has a tiny syntax.
Lisp has uncountable years of development.
Lisp had lots of people who wanted it to go fast, so it goes fast.

Ruby has a huge syntax.
Comparably, Ruby has a thimbleful of years of development.
Ruby has lots of people complaining about it being slow but only a handful of people doing something about it. (No, I don't consider myself someone who is doing something about it.)

Its harder to make ruby go fast because its a bigger thing to optimize and there are less people willing to attempt it it. Look at Squeak for inspiration, though.

Mostly you need enough people with enough brains and enough desire to make ruby go faster. (But really, you don't need the brains, they'll grow as you go.)

···

On May 23, 2006, at 12:15 AM, Alex Young wrote:

Francis Cianfrocca wrote:

I've always had a sense that some of what makes Ruby so beautiful is
_precisely_ what makes it slow. Some of this is a matter of
implementation (if anyone remembers the early implementations of ML,
you know what good tail-recursion can do for you. Plus Ruby seems to
get super-linearly worse as its working set grows), but some of it is
fundamental. Metaprogramming is very hard to do without depending on a
lot of string comparing at runtime. I've got a language design
background (I made a lot of money writing compilers for scripting
languages), and I've had to deal with this problem in other languages.
YARV looks like beautiful work, but I have a gut-feeling that it won't
solve the "speed" problem all by itself.

Maybe you're the one to ask then. With all the talk of VMs, everyone seems to make the comparison to Java and Python. Surely Lisp is a better comparison? Lisps can be stupid fast (as mentioned in another response to this thread), so what does Lisp do right that Ruby doesn't?

--
Eric Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com

32

> Ruby is based on gcc, gcc has grown some nifty ways of speeding things
> up.

No. Ruby is *not* based on gcc. Ruby is based on ANSI C. Any
GCC-specific performanced boosts would reduce Ruby's portability.

> Currently Ruby is compiled -O2 usually for generic i386
>
> Obvious answers
> - Compile -O3, gcc, especially since version 4.0 has grown some really
> nifty optimizations. Almost the whole point of version gcc 4

Be careful that those optimizations don't omit stack frames. You'll
get an unusable Ruby.

> Ruby is _not_ gcc warning clean. Some gcc warnings are actually
> performance related.

Ruby should try to be clean on all compilers that don't try to give
you warnings about compiler-specific things (like Visual Studio's new
warnings about deprecated functions like printf).

All that said, the best thing one can do to improve the performance of
one's Ruby script is to have hard numbers about where your script is
performing poorly and being absolutely *certain* that it's Ruby and
not your algorithm. (That is, I know exactly why PDF::Writer is as
dramatically slow as it is; I just don't have a fix for it, yet.)

Can anyone recommend some good or tutorials on profiling and benchmarking?
Although I have used them both (from the standard library), I feel I lack
fundamental knowledge about how to go about it.

Mark

···

On Tuesday 23 May 2006 12:41, Austin Ziegler wrote:

On 5/22/06, John Carter <john.carter@tait.co.nz> wrote:

-austin

33

Ruby is based on gcc, gcc has grown some nifty ways of speeding things
up.

No. Ruby is *not* based on gcc. Ruby is based on ANSI C. Any
GCC-specific performanced boosts would reduce Ruby's portability.

And so? Nothing I suggested would reduce Ruby's portability, and the
Function inlines is based on C99 standard and is available on
practically any compiler that also does C++.

Be careful that those optimizations don't omit stack frames. You'll
get an unusable Ruby.

By default it doesn't on x86 since that makes programs hard to debug.
But you can make that explicit with -fno-omit-stack-frames

Ruby is _not_ gcc warning clean. Some gcc warnings are actually performance related.

Ruby should try to be clean on all compilers that don't try to give
you warnings about compiler-specific things (like Visual Studio's new
warnings about deprecated functions like printf).

Things like alignment and strict aliasing improve speed on most
compilers / platforms.

All that said, the best thing one can do to improve the performance of
one's Ruby script is to have hard numbers about where your script is
performing poorly and being absolutely *certain* that it's Ruby and
not your algorithm. (That is, I know exactly why PDF::Writer is as
dramatically slow as it is; I just don't have a fix for it, yet.)

At no stage have I ever blamed Ruby for the slowness of my scripts, most
times Rubies power and flexibility has enabled me to use faster
algorithms.

The following items are each an order of magnitude less important in
matters of speed.
* Scope - Try doing less.
* Algorithm * Code Optimizations.
* Ruby Interpreter Optimizations.

Even though the Ruby interpreter optimizations are the least effective
optimization, they have the nice property of applying instantly and
cheaply to all scripts.

My aim is not to complain about the weather, but to suggest simple
concrete actions that can be taken by the Ruby community to improve the
speed of the _current_ Ruby interpreter for most applications.

* Provide a performance benchmarking suite that is relevant to the
   Ruby user community. * Adopt a file and make it -Wall -W (perhaps with a sprinkling of -Wno-)
   clean.
* Tweak the configure and automake to use profiling & coverage options in
   gcc to...
   - Give a coverage report on our test suite.
   - Give a profile report on the performance benchmark.
   - Perform profile based branch prediction.
* Provide instructions / and perhaps a ./configure --option to use
   -march= and/or -mtune
* Analyse the coverage report and generate new test cases to extend coverage.
* Analyse the profile report and contemplate performance tweaks.
* Produce cachegrind reports and contemplate performance tweaks. (eg. Simple one is
   sometimes -Os does better than -O3 for cache reasons!)

What I have proposed is ...
   * Concrete.
   * Simple to do.
   * Every Ruby user can pick an item on this list and contribute some small
     but meaningful thing.
   * It doesn't push the problem onto some magical someone or something else.
   * Much is reusable even if we do go to YARV or whatever.

John Carter Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : john.carter@tait.co.nz
New Zealand

Carter's Clarification of Murphy's Law.

"Things only ever go right so that they may go more spectacularly wrong later."

From this principle, all of life and physics may be deduced.

···

On Tue, 23 May 2006, Austin Ziegler wrote:

On 5/22/06, John Carter <john.carter@tait.co.nz> wrote:

34

:slight_smile: Woah! Now hang on there.

I was giving a response to:
  "Are there valid excuses for not focusing on improving Ruby's poor computational performance?"

And to paraphrase myself, the answer is:
  Yes

However, as I said, I'll be as happy as the next about any performance improvements.

···

On 22 May 2006, at 17:18, cremes.devlist@mac.com wrote:

On May 22, 2006, at 10:07 AM, benjohn@fysh.org wrote:

*snip*

So what is being done to get YARV the attention it deserves? Why
aren't we talking about it all the time? What can I personally do to
help? Are there valid excuses for not focusing on improving Ruby's
poor computational performance?

There vertainly are perfectly good "excuses" (I didn't know I needed
one! :slight_smile: ) for not focussing on Ruby's performance - it's performance is
only a concern for one (poor or otherwise) if it's actually causing one
a problem.

In my previous incarnation as a signal processing and volume rendering
coder, I imagine Ruby's performance would have been unnaceptable. In my
current role as a testing framework programmer, it's plenty fast thanks,
and jolly expressive. I've no reason (at the moment) to require more
performance from it. When I switch back to doing graphics again, I'll be
generating my c, c++ or assembly with Ruby anyway, rather than hand
coding it, and it'll probably be fast enough for that too.

Not to single you out (though I guess I am) but you are the first one in the thread to write-in with "it's good enough for me because of <insert reasons having nothing to do with computation speed here>."

35

There are big problems with this approach. None of gcc's optimizations
beyond -O2 come for free. They usually enlarge the binary, make
debugging really hard, impact thread-safeness or even correct
functionality (omit frame pointer).

You already have instruction reordering and register only
variables at -O2. ie. Debugging is already hard.

You can switch off -fomit-frame-pointer

Vomit frame pointer doesn't break correct C functionality, just makes
debugging harder.

One of the nice things about Rubies non-native thread implementation
is... it's not multithreaded from the C code point of view!

Certainly some of the optimizations can make the binaries larger, on a
desk top who cares?

Some optimizations may make ruby slower, that is why I said, explicitly
upfront item number 1, we need a standard benchmark suite of "typical"
ruby applications so we can know whether we are improving things or not.

Reworking ruby for better alignment of memory accesses might be
useful. After determining how much of a problem it is though.

Yip, last time I look at the i*86 CPU instruction cycle counts, the penalty
for misaligned references was significant.

John Carter Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : john.carter@tait.co.nz
New Zealand

Carter's Clarification of Murphy's Law.

"Things only ever go right so that they may go more spectacularly wrong later."

From this principle, all of life and physics may be deduced.

···

On Thu, 25 May 2006, Juergen Strobel wrote:

36

though clearly you would accumulate some mighty bad karma if you'd done so :wink:

a @ http://codeforpeople.com/

···

On Jun 23, 2008, at 8:24 AM, M. Edward (Ed) Borasky wrote:

The way I interpret open source licenses, if you take an open source toolset, squeeze all the major bottlenecks out of it and put it into production in a server, there's no requirement for you to release the source of your hacks as long as you don't attempt to distribute the resulting binaries. :slight_smile:

--
we can deny everything, except that we have the possibility of being better. simply reflect on that.
h.h. the 14th dalai lama

37

put it into production in a server [...]
as long as you don't attempt to distribute the
resulting binaries. :slight_smile:

Your server or the server of a client?

38

I could be wrong, but I believe that only applies to the BSD license.
Not the GNU one.

Chad

···

On Jun 23, 7:24 am, "M. Edward (Ed) Borasky" <zn...@cesmail.net> wrote:

Roger Pack wrote:
>> YARV and Ruby's poor computational performance. Zed said, and I quote:

>>> I?ll be honest right away though and say that Ruby is slow. The
>>> Ruby community has been ignoring the huge ?performance? elephant
>>> standing in the room and they need to start talking about it so it
>>> goes away. Elephants hate being talked about. There are a few
>>> efforts to make Ruby faster, but I see a lot less action than is
>>> needed to solve the problem. One solution in the works is a real
>>> virtual machine called Rite (or YARV depending on who you talk to)
>>> which is showing some real promise and seems to be speed
>>> competitive with the fastest Java implementations.

> Yeah I have come to the sad conclusion that, at least with the 1.8.x
> world, if speedy execution is your goal you should probably choose
> another scripting language [python+psycho comes to mind]. Especially
> when considered in conjunction with rails. There I have mentioned the
> elephant :slight_smile:
> That being said, thankfully 95% of web pages and scripts don't really
> care about getting hammered, since they never will be. But the other 5%
> will suffer until this gets figured out. And I'm not volunteering.
> Hopefully this will improve in the near future. Until then back to my
> coding of some poorly performing, elegantly written web pages.
> -R

Well, Zed's rant *was* published some time ago -- before the 1.9.0
release, I think. I know very little has changed in the MRI performance
arena, but "Rite" and "YARV" are the same thing as far as I know and
are/is indeed faster at the core than MRI.

As far as Rails is concerned, though, quite a bit of work is available
on the web on hacks for tuning it, things to avoid in your Ruby code,
etc. I suspect there is more that *isn't* publicly available on tuning
Rails.

The way I interpret open source licenses, if you take an open source
toolset, squeeze all the major bottlenecks out of it and put it into
production in a server, there's no requirement for you to release the
source of your hacks as long as you don't attempt to distribute the
resulting binaries. :slight_smile:

I've speculated a bit on what I think might happen in my blog.

39

Kyle Schmitt wrote:

···

On Mon, Jun 23, 2008 at 7:09 AM, Roger Pack <rogerpack2005@gmail.com> > wrote:

-R
--
Posted via http://www.ruby-forum.com/\.

Agreed, but hasn't this dead horse been beaten enough?

I would call them a sadistic necro-equine but that IS beating a dead
horse.
--
Posted via http://www.ruby-forum.com/\.

40

Kirk Haines wrote:

The thing that always stands out to me in these performance discussions is that people argue that Ruby needs a performance improvement, but there are rarely any specifics attached to that analysis.

Very good point.

...

Ruby can be a bottleneck, but for the vast majority of Ruby users and the vast majority of tasks people use if for, it is not the bottleneck.

It is not an elephant in the living room that everyone is ignoring if the performance simply isn't a limiting factor. It's an elephant out in the paddock, where it belongs in those cases. And those cases are the majority of cases.

Or it's the hamster in the living room. People don't comment on it because, for the most part, they don't see it.

Those people having speed issues: Is it not a reasonable option to replace the bottleneck Ruby code with custom compiled C libraries?

I tend to offer that as the general speed solution, but don't have all that much experience with it. I've written Ruby modules in C as an educational exercise, and found it to be as easy as people say it is, but I've not had to do it in Real Life.

I'm curious if this is as good an option as I've been inclined to believe.

···

--
James Britt

"You harmonize; then you customize."
  - Wilson Pickett