ko1 / atdot.net wrote:
> Issue #12967 has been updated by Koichi Sasada.
> 
> Status changed from Open to Rejected
> 
> > My suggestion is to ship with a far safer default of: RUBY_GC_HEAP_GROWTH_MAX_SLOTS=100000 
> 
> To define "safe" is difficult. Providing tuning parameter is enough for this purpose.

I think a problem is few people know tuning parameters (even if
we documented in the ruby(1) manpage), and some tuning parameter
behaviors may change with time.

So, we should try to find better defaults for the common case.

Maybe it's just me, but I have more problems with memory usage
than speed with Ruby.  I think Sam and most other Rails users
will agree with me.

For tracking down high memory usage in apps, I prefer
single-threaded servers since it's easier to track down what
code was executing when big growths happen.  But single-threaded
is also not memory-efficient....

Unfortunately, tracking/controlling memory growth in a
multi-threaded, shared heap processes is not easy, either;
especially when they have to know how their malloc()
implementation works, and what tuning there is, too.

In my experience, typical Ruby programmers would rather not be
going through their entire code base to hunt memory growth
locations, regardless of single or multi-thread.  Instead, I see
people either buy more memory, or abandon Ruby.

Anyways, I don't think RUBY_GC_HEAP_GROWTH_MAX_SLOTS=100000
will hurt anyone.

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>