> Basically, if you are that concerned about memory efficiency, a few
> comments would be:
> 
>   1. perhaps you don't "get" Ruby.  It was designed in such a way that
>      you don't need to worry about allocating and deallocating memory.
>      Ruby does both for you automatically, freeing you to worry about
>      the real problem you are trying to solve.

I am aware of that.

>   2. If your concern is a valid one within the problem domain you are
>      trying to solve, then Ruby is probably not the best language to
>      use for that problem.

If my concern was speed, then yes I agree with you. But I don't see why 
Ruby programs should consume much more memory than C programs for example.

>   3. If it takes you more than an hour or so to solve a memory efficiency
>      problem, you might want to ponder on the fact that at standard
>      contract programming rates, you could buy several more megabytes
>      of memory with what a contract programmer's time is worth.

Sure, and when speed is a problem I could get a faster processor, what 
do I need a profiler for?

>   4. While, in the large, you do want to select an algorithm that makes
>      the best use of memory, you don't want to sweat the small stuff too

In that case you still need to measure the amount of memory used.

>      much.  Efficiency is doing a job right, but effectiveness is doing
>      the right job.  First, think about it a bit and make sure that 
>      focusing on memory efficiency is an effective use or your time.

My concern is that it does make a difference if clients need 256MB, 
512MB or 1GB of RAM to use your program.

   Erik