Alexey Verkhovsky wrote:
Nope, and I don't see them in Java profiler, either.
Then they probably are not hot spots, like you suspect. Which leaves open potential for the future.
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.
However, this assumption has not played out in practice. With the compiler enabled and fully compiling, we are faster than MRI for almost all such benchmarks where we have an abstraction in JRuby on top of Java's own data structures. So a piece of Ruby code, working with a data structure implemented in Java in JRuby, on top of the JVM...and still we come out faster. In some cases, we come out faster even in *interpreted* mode. But the challenge to getting there is to make it possible for Java to optimize the full call path better. That means continuing simplification and more compilation.
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:
...
Point being, not many of these methods would be radically faster with a bytecode engine (unless I misunderstand the concept).
Well, there's more going on here than is visible through a simple profile. The items that have sped up RDoc in the past have been almost entirely unrelated to profiling results, which is why it's been so frustrating. For example, over the weekend I modified exceptions to defer creating a backtrace until backtrace was actually called. It trimmed off 2 seconds on my system out of a usual run of 33-35s. And nothing related to exceptions ever showed up in any profiling runs.
The truth is that we're at a point of optimization where typical Java profiling isn't telling us the whole story. Removing complexity, simplifying call paths, removing decision points or making decisions once all affect HotSpot's ability to optimize the code. So our long-term approach to RDoc has been to just keep on simplifying the rest of JRuby, and we've managed to make measured gains along the way. Combine that with more optimized, shorter-path implementation of the core classes and more and more compilation, and things are still looking good for the future.
This also ignores the fact that RDoc is an extremely short-lived benchmark in the grand scheme of things. In a few experiments, I ran multiple RDoc runs in succession with the server VM enabled and numbers improved drastically. So for a short process like RDoc generation, we pay the price all short-lived Java programs pay. And unfortunately there's not much we can do to get around that in the short term.
Have faith :) - Charlie --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
