On 5/22/07, Charles Oliver Nutter <[EMAIL PROTECTED]> wrote:
but if that's one of the primary performance issues for rdoc
Not sure if it will be a big win for RDoc. It may. Generally, making sure that RDoc internals are JIT-compiled would certainly help. As a matter of fact, I don't see -any- compiled methods in the profiler call tree when I run RDoc. So far, I don't quite know why - it certainly does compile some stuff (i.e., JIT is not completely disabled). Like I said, so far there is no big win that can be seen at the interpreter level. No obvious bottleneck. Other than making sure that it's all somehow compiled to bytecode. There is an obvious bottleneck at the app code level (where RDoc is the app). I could just say "let's sit down and rewrite rdoc/parse_rb.rb and irb/slex.rb in straight Java - this stuff is too close to the metal for dynamic execution". And it would speed things up umpteen times. But that's not an option if we are shooting for comparable interpreter performance and complete reuse of MRI standard library. At that level, I don't see any big wins available without a drastic change of direction. JVM, however fast, should be slower than C for primitive byte-pushing. And that's exactly what's involved in RDoc. E.g., there are about 4 calls per -micro-second (NB: micro, not milli) to EvaluationState#evalInternal going on there. This method itself only takes like 9-10% of CPU time (if you believe a profiler, which at that level of call rates is a big if). But then, I only played with this codebase for a couple of days so far, so I may just be blind. -- Alex --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
