Charles Oliver Nutter wrote:
It's probably safe to assume that almost all of the core types we
autoconvert are suffering from this performance hit right now, because
they all rely on a generic piece of code with a bunch of stacked object
comparisons to do conversion. And the change I made would just as easily
apply to parameters being passed into Java code...we'd just have an
array of converters for the incoming parameters that would only focus on
conversion to a single type...the type we want for the call.
Ok, here's another likely bottleneck.
JavaMethod calls invokeWithExceptionHandling when the method is called.
That takes the result and calls JavaObject.wrap. JavaObject.wrap wraps
everything in some instance of JavaObject and puts it into the global
wrapper cache.
However for String and the primitive types, this JavaObject never
actually makes it to Ruby-land. We do a *second* conversion to make them
Ruby String, Fixnum, etc using the slow logic there. We wrap Strings and
primitives without ever using the wrappers, even though they're cached.
Seems like another opportunity.
One thought I had, if we really wanted to make Java Strings/primitives
wrapped types in JRuby would be to have them just extend the appropriate
Ruby type; i.e. Java string would enter the system as a type < String,
and the others similarly. They'd still be JavaObjects in Java-land, and
we could get the wrapped type out, but they'd look like the real Ruby
types otherwise.
Thinking out loud.
Of course lightweight support could make a lot of this go away. I keep
circling around to the same four or five areas to work on.
- Charlie
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
