On Mon, May 9, 2011 at 9:20 AM, Daniel Lucraft <dan.lucr...@gmail.com> wrote: > On Monday, 9 May 2011 at 14:58, Thomas E Enebo wrote: > > On Mon, May 9, 2011 at 8:16 AM, Daniel Lucraft <dan.lucr...@gmail.com> > wrote: > > * use thread times from ThreadMXBean instead of the global process > cputime (possibly only when there are multiple jruby threads as this > will slow > things down) > > This seems like a really useful improvement. Second best (and a very > close second) in the list in my opinion (behind API toggling). > > Good. It'll be interesting to see how much it slows things down. > > * add an HTML output mode > > I think it should be put in a format which can be transformed (dare I > say the format????). At a bare minimum, it should be well-formed HTML > to allow transformation. XHTML-like for easy viewing, but still a > data format so people can re-purpose the data for other types of > display.
If it is very simple well-formed HTML then I think people can use things like XSLT to transform into other formats. It will also still display, which is a bonus. > Yeah, I had a request for some kind of parseable format before. Any > suggestions? JSON/CSV/XML+XSLT? Or is there a standard for this kind of > thing? > > * make it possible to turn the API on and off during a Jruby process > execution (will need help with this one) > > I think this one will be killer. Targeting what you want to measure > is really nice. Profiling all of Rails startup to just try and > profile where a controller is spending time can be a bit much. > > Actually you can already do this. See How to Profile Blocks of Code > in http://danlucraft.com/blog/2011/03/built-in-profiler-in-jruby-1.6/ > > The improvement here is to not require that --profile.api be passed in. This > flag makes JRuby use the ProfilingDynamicMethod type instead of... whatever. > Because it is a bit slower to use that class even when profiling is not > happening, we want to not require it be turned on always. But it's hard to > swap out all the existing DynamicMethod objects when we turn the profiling > on. > In truth I don't understand much of that :), ask Charlie when he gets back, > he was pretty keen on making this change. Yeah, Actually I understand the difficulty here. We could collapse ProfilingDynamicMethod checks into our base class, but even that will be measurable (though very small -- microbenches are the only thing which shows the overhead). -Tom -- blog: http://blog.enebo.com twitter: tom_enebo mail: tom.en...@gmail.com --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
