I would really like to see it off by default.
(disable ObjectSpace by default)++
On 28/10/2007, at 18:42, Thomas E Enebo wrote:
Too bad we cannot preserve original 1.0 semantics and have -O turn off
Objectspace and +O enable it. Then we can default to -O. -O really
just keeps getting worse and worse (comparatively to not having it
enabled) and people generally do not realize they can disable it. So
I have come around on this and also think it should be off by default.
-Tom
On 10/28/07, Charles Oliver Nutter <[EMAIL PROTECTED]> wrote:
So, it's time to bring up this question. ObjectSpace makes JRuby
so much
slower, I think it's time to consider disabling it by default.
For example, here's the fractal benchmark, which generates a text-
based
mandelbrot:
With ObjectSpace: Ruby Elapsed 45.967000
Without ObjectSpace: Ruby Elapsed 4.280000
We have also made modifications to allow ObjectSpace.each_object
(Class)
to work even when ObjectSpace is disabled, by tracking an in-memory
graph of classes and subclasses. This allows the most visible use
case
for ObjectSpace--test/unit--to continue working until we can patch
it to
not use ObjectSpace.
So I have a few questions here:
- Could we now use -O to *enabled* objectspace?
- Would a requirable library be better? -robjectspace to enable the
"extended" features for full object graph walking?
- Do we know of anything else that needs ObjectSpace? Can we get
those
things patched?
- Do we need to get buy-in from ruby-core for something like this?
Can
we convince them it's in everyone's best interest if ObjectSpace
becomes
an extension?
Over time, our perf numbers have shown ObjectSpace as more and
more of a
penalty. I'm tired of typing -O, but I'm not running a lot of real-
world
stuff day-to-day. What do you all think?
- Charlie
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
--
Blog: http://www.bloglines.com/blog/ThomasEEnebo
Email: [EMAIL PROTECTED] , [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
--
Fabio Kung
http://www.fabiokung.com
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
