From: Victor Shepelev <vshepelev@...>
Date: 2006-05-23T01:52:18+09:00
Subject: Re: Zed and Luis drop the bomb on Ruby's poor performance

From: ara.t.howard@noaa.gov [mailto:ara.t.howard@noaa.gov]

> 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.

Makes sense. But.
I'd like to think about things like "reasonable slow" and "unreasonable
slow"; and Ruby sometimes is just __unreasonable__ slow. Here are some
examples:

* I'm working with custom UI library, which is based on HTML (namely, on
terrainformatica.com/htmlayout). There are a large amount of objects created
corresponding to DOM tree nodes ("large" means thousands) and profiler says,
that one of the slowest operation is Class#new - is it normal?

* 5000 objects is loaded from database (by SELECT'ing and setting fields).
The major slower is that each object has Date field (Integer#gcd is very
slow). Or Kernel#send (I use it because of my DSL created) and so on.

Summarizing, after large profilings and optimizations, there are oftenly
some core methods (even Fixnum#+) show themselves as major speed problems.

This situation I call "unreasonable slow".

> -a

Victor.