The following message is a courtesy copy of an article
that has been posted to comp.lang.misc as well.

"Conrad Schneiker" <schneiker / jump.net> writes:

> Let's say you have a really grandiose Ruby application that tries to
> function as a general purpose assistant with respect to all the things that
> the modules in the supported Ruby distribution can do. Let's say you have a
> very fast file system and many 100s of megabytes of RAM. For purposes of
> minimizing startup time, could _all_ the modules first be imported, then
> initialized, and finally, could the process execution image at that point be
> saved for subsequent restarting, at which point the main program would
> proceed? Are there problems with dynamic linking of Ruby extensions and such
> that would thwart any substantial time savings? Are there any modules that
> set global variables in incompatible ways upon initialization?

Well, Ruby modules are often not like this. Unlike (say) Perl, they
often contain code that is meaningless in isolation, but that has to
be mixed-n the other code. These modules do not have initialization
per-se, they encapsulate abstract behavior.

Now I guess to fit this scheme, you could pre-compile them all, and
then save out the Ruby image that contained the symbol table and parse 
tree, making them instantly accessible to subsequent programs.

But, I'm not sure this would be a major win. Two problems spring to
mind:

1. The scheme relies on the OS caching an in-memory image of the
   mega-Ruby, so that start-up times are not compromised. On OSes that 
   don;t do this, the scheme slows Ruby down, as all the unused stuff
   is loaded in each time.

2. You're adding a heap of unused stuff to the tables of global
   constants and variables. I don't know, but I'm guessing this will
   slow down name lookup to some extent. This overhead will apply to
   _all_ programs, from "Hello World" on up, regardless of whether
   they use the features.

However, I *do* see merit in the scheme. If you want to bundle a Ruby
application that uses a lot of library functionality, it would be
easier to be able to ship one file, not twenty. Maybe having some kind 
of dump mechanism, a la TeX, would be useful in those circumstances.


Dave


-- 
Thomas Consulting.
Innovative and successful developments with Unix, Java, C, and C++. 

Now in bookstores:
 The Pragmatic Programmer.  www.pragmaticprogrammer.com/ppbook/