Ola Bini wrote:
I was thinking if the slowness of loading is because of all the class
loaders used... Would it make sense to let the standard library run with
the same class loader, you think?
And in the same manner, when we're talking about compiling RubyGems on
installation, having the same class loader for the whole gem seems to
make sense, neh?
Yes, I have been thinking the same thing, and trying to reconcile how to
know when we should switch to a different classloader for new methods.
Since "def" is always a runtime operation, there's no clear distinction
between doing
while true; def some_method; end; end
and doing
def some_method; end
But the first case would leak classes if it always generated, say,
invokers into the same classloader.
I also would like to find a way to reduce the overhead of starting up
the class, possibly by generating a single custom call adapter per
compiled class that has custom methods for each call site and n * 3
fields for the inline cache; that would allow a single object to be
constructed rather than one per invocation.
There's a lot of room for improvement here.
- Charlie
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
