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. 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. > Question...If you toggle on and off and on and off..will it throw away > previous results or will it accumulate them? (I imagine the answer > could be both) One reason for asking is that I might want to > demarcate a method > to toggle on and off at the methods boundaries. After 1000 > invocations, it would be nice to see the cumulative result. Good thinking. In theory accumulation should be easy enough. Though it can be tricky to reconcile different starting points for profiling (esp. with recursive methods), but we can try and get it working. Thanks. I wasn't even sure if my emails were getting through to the list :) Dan ______________________________ Daniel Lucraft danlucraft.com/blog twitter.com/danlucraft
