I probably did. It's QUITE flexible, but out of the box it can provide an nice tree of calls with execution times and hot-spot identification.
FYI, our biggest performance complaint *appears* to be startup. It's quiet possible that it's because we include so many java classes, but we have what appear to be really slow startup times. David On Wednesday 29 March 2006 09:48, Thomas E Enebo wrote: > This seems to be the right time to mutate the thread into a favorite > java profiler thread....Anyone have any recommendations? I think last > time David mentioned JRat. > > -Tom > > On Tue, 28 Mar 2006, Charles O Nutter defenestrated me: > > This is an experimental patch to remove the creation of > > "InstructionBundle" objects for each node encountered in the AST. The > > InstructionBundle was originally added to support the iterative > > algorithm for handling branch events like next, break, rescue, and so > > on. An InstructionBundle is created each time a node is encountered, > > and holds the node, the instruction to execute against it, and a > > number of flags indicating whether this node should be the target of > > one of those interpreter events. > > The idea behind this patch was to start narrowing down exactly where > > our biggest interpreter performance issues come from. One possible > > cause for things running a bit slower in recent months was obviously > > the creation of all those InstructionBundle objects. However, removing > > their creation and going back to two separate stacks for instructions > > and nodes (instruction contexts) actually caused it to slow down more > > than it sped up...by about 10% in one algorithm I ran. This would > > indicate that the extra overhead of managing a second stack for every > > Ruby method invocation is a greater cost than creating many > > InstructionBundle instances managed in a single stack. > > This continues to point toward the benefits a compiler or a > > "pre-evaluator" would give us. By either compiling the Ruby code down > > to static lists of instructions we would eliminate the current > > "instruction stack" model completely, lowering the per-node overhead > > in the interpreter. We would also have the option of potentially > > combining multiple instructions into a single interpreter loop. > > Anyway, the patch is attached for your edification. It's not something > > I'm planning to commit, but it is demonstrative anyway. > > -- > > Charles Oliver Nutter @ [1]headius.blogspot.com > > JRuby Developer @ [2]jruby.sourceforge.net > > Application Architect @ [3]www.ventera.com > > > > References > > > > 1. http://headius.blogspot.com/ > > 2. http://jruby.sourceforge.net/ > > 3. http://www.ventera.com/ ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Jruby-devel mailing list Jruby-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jruby-devel
