Hi Davide, Recently Ian pointed to Metrics [1] project which is related to such timing measurements. It might be helpful to use this (via a wrapper) to measure timings in critical areas in Oak. So have a look at that also
Chetan Mehrotra [1] http://metrics.codahale.com/ On Sat, Aug 2, 2014 at 2:57 PM, Davide Giannella <dav...@apache.org> wrote: > On 23/06/2014 14:26, Davide Giannella wrote: >> On 23/06/2014 13:57, Michael Dürig wrote: >>> +1 in general. However, >>> >>> - although it results in nice code on the client side, I'm a bit >>> reluctant about putting all the code into the instance initialiser. >> it was my concern as well. But don't see that much of a difference from >> something >> >> timer = new Timer("foobar"); >> timer.start(); >> // blabla >> timer.trackTime(); >> >>> - how about reusing org.apache.jackrabbit.oak.stats.Clock instead of >>> using Guava's Stopwatch? If necessary we could still implement Clock >>> based on Stopwatch. >> Didn't know about it. Will have a look and amend accordingly. >> >>> - Timer might not be the best name for the class. Should probably >>> better be something with "Log" in its name >> It was an example. It could be LogTimer if you prefer or whatever. Don't >> mind the name and I'm very bad at it :) > Had time on train to work a bit on it. > > here's a the final class > > http://goo.gl/xUcPdY > > The idea behind it is to have something for tracking time like > > // ... > StopwatchLogger sl = new StopwatchLogger(FooBar.class); > // ... > > public void foo() { > sl.start(); > // perform all sort of things > sl.split("performed some operations"); > // perform other things > sl.stop("operation completed"); > } > > then by setting in logs the debug for o.a.j.oak.stats.StopwatchLogger > should do the trick to have some "gross" numbers around performances. > > If ok, I'll create an issue an commit to trunk. > > thoguhts? > > Cheers > Davide >
