From: Jan Svitok <jan.svitok@...>
Date: 2006-11-27T17:19:14+09:00
Subject: Re: Two Advanced Ruby Performance Questions

On 11/27/06, Sunny Hirai <sunny@citymax.com> wrote:
> Hi All and thanks for the responses.

> 3. I address the overhead of web services operations constantly. Even
> when working within the SAME language, I benchmark overhead and test the
> cost of each operation. For example, ColdFusion has a native WDDX (XML
> like) conversion format that we used to use to fold multiple fields into
> a single field for caching in a database. After testing, I wrote a
> custom encoding/decoding format that executes about 1-2 orders of
> magnitude faster if I remember correctly. I also weigh the cost of
> calling methods. In fact, one of the major reasons for wanting a switch

It is said that method call overhead in ruby is pretty high, partially
due to the possibility of being able override an existing method
later.

> I found some of the information I wanted in not the eRuby or ERB pages
> but in mod_ruby.

Both ERB and eRuby will compile your template into a string that will
get 'eval'ed. The difference is that ERB uses print statements and is
therefore hard to capture.
Have a look at erubis -- ERB implementation in C (I haven't tried it myself).

> It suggests that ONE instance of Ruby executes to handle all the
> threads; however, it doesn't go into too much detail about how this is
> handled. So, for example, if I call

The usual way to deploy ruby application is either using
mod_fgci(d)/fast_cgi or using mongrel or webrick as a container and
proxying to them. (Proxy to Mongrel seems to be the easiest one).

Mongrel is able to run in multiple threads, rails not. The problem is
somewhere in the metaprogramming magic (though I don't know precisely
where). This limitation is worked around by running multiple instances
of mongrel with multiple ruby interpreters. These interpreteter share
nothing by default among them (except db). You can have them share
sessions, etc. by using db or shared memory  for it.

Within one interpreter, classes are persistent. I.e. the life cycle
is: the interpreter starts, initializes, and serves requests in a
loop. The classes you define stay there until interpreter is stopped.
Instances/objects are created on the run as needed. They are not
recycled. However it may be possible to create a factory method that
will cache created instances and reuse them. That will possibly make
your code more complicated and error prone...

> I still don't know whethere eRuby can be called from within Ruby or if
> it has to be called from the command line or through some sort of
> adapter.

You can call it from ruby as well. There's not a lot of documentation,
but it's certainly possible. Ask me when you'll need it and I'll send
an example to you.
(OT: I sent a doc patch to Shugo Maeda, but got no response.)
However eRuby will not work as it is with rails due to the print statement.

> I feel like Ruby needs a "High Performance Ruby" book. There is one for
> MySQL and that is the only reason I had the confidence to make the
> decision to switch out of MS SQL Server. Knowing what I'm up against
> would help tremendously.
>
> Thanks for your feedback. If anybody knows anything more about the guts
> of mod_ruby and/or Ruby, please let me know.
>
> All the best,
>
> Sunny Hirai
> CEO, MeZine Inc.