On 5/22/07, Charles Oliver Nutter <[EMAIL PROTECTED]> wrote:
If you're running with code older than a few days ago
Why would I? Of course not. I'm doing svn up as often as I can.
, you won't see JIT compiled methods in -rprofile.
Nope, and I don't see them in Java profiler, either.
> Like I said, so far there is no big win that can be seen at the > interpreter level. That's about the determination we've come to, but it still feels like it's a lot slower than it should be.
It does. But that's because we have really basic stuff (iterating through byte arrays with interesting parsing logic in between) implemented in one abstraction (Ruby) on top of the other (JVM). So, it's not entirely surprising.
The hope for EvalState#evalInternal is that it can be replaced with a bytecode engine in the near future.
Thing is, it was ONLY 10% of CPU in those tests. Other equally big suckers (according to sampling profiler, anyway) are as disperse as this: RubyObject.IsTrue (10%) - maybe due to target being declared as IRubyObject and therefore it compiles to invokeinterface instead of invokestatic. Worth experimenting with. ObjectSpace.cleanup (7%) ArrayList.ToArray(), invoked from DefaultMethod.prepareOptOrRestArgs() (6%) RubyObject.getInstanceVariable(), mostly invoked from ThreadContext.getConstant() and RubyModule.getConstantInner() (6%) - by the way, this is not because the hash is lazy-instantiated there (I tried to change it, with no positive effect). RubyModule.getMethods() (3%) RubyObject.getMetaClass() (3%) etc. Point being, not many of these methods would be radically faster with a bytecode engine (unless I misunderstand the concept). -- Alex --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
