From: Brian Candler <B.Candler@...>
Date: 2004-11-02T23:49:30+09:00
Subject: Re: fastcgi performance problems and ruby

On Tue, Nov 02, 2004 at 11:29:09PM +0900, trans.  (T. Onoma) wrote:
> I'm also curious about Singleton Class, i.e. I recall (it was a while ago) 
> somthing about modifying CGI to be a Singleton class rather then a regular 
> class --that seemed helpful.

That sentence doesn't make much sense to me - can you define what you mean
by "modifying .. to be a Singleton class rather than a regular class" ??

Remember that:

1. CGI is_a Class (i.e. CGI is an object, an instance of class Class)

2. This object has a singleton class; that is, methods which apply to
   CGI itself, and not to any instance of class CGI, nor any other
   instance of class Class.

   For example, CGI.escapeHTML is a method within CGI's singleton class

3. Singleton classes are anonymous; there is no need to name them, as they
   are always only associated with one object.

So I can't really make sense of what you're suggesting. If you've not seen
it, have a look at http://www.rubygarden.org/ruby?SingletonTutorial and see
if that makes the terminology any clearer.

The issue with performance is: CGI.new creates a new object (an instance of
class CGI), and at object creation time, a whole bunch of methods are added
at run-time to that instance's singleton class.

e.g.

  a = CGI.new("html3")
  b = CGI.new("html4")

creates two objects, each of which is an instance of CGI, but if you look in
the source for cgi.rb you can see a lot of work is done in the initialize()
method:

    case type
    when "html3"
      extend Html3
      element_init()
      extend HtmlExtension
    when "html4"
      extend Html4
      element_init()
      extend HtmlExtension

In turn, method element_init does a whole load of work defining methods the
slow way, with code such as

      for element in %w[ A TT I B U STRIKE BIG SMALL SUB SUP EM STRONG
          DFN CODE SAMP KBD VAR CITE FONT ADDRESS DIV center MAP
          APPLET PRE XMP LISTING DL OL UL DIR MENU SELECT table TITLE
          STYLE SCRIPT H1 H2 H3 H4 H5 H6 TEXTAREA FORM BLOCKQUOTE
          CAPTION ]
        methods += <<-BEGIN + nn_element_def(element) + <<-END
          def #{element.downcase}(attributes = {})
        BEGIN
          end
        END
      end
      ...
      eval(methods)

I'm sure this was to save the programmer having to enumerate all these
methods in the mixin, but I'd have thought it could be done more
efficiently than that (by defining the methods once in the mixin, not at
run-time in every object instance)

Perhaps the assumption in the CGI library is that normally a CGI is a
one-shot process: there is no point carefully preparing mixins for
Html3/Html4/Html4Tr/Html4Fr if at runtime only one will be used and then the
CGI will terminate. But that assumption is not true for a FastCGI
environment.

But actually, if you just use CGI.new without passing a html type, this
heavyweight construction work isn't done anyway.

Regards,

Brian.