on java < 5 backport-util-concurrent is required to provide System.nanotime()
I've no idea of the result of such a bench on other JVM / architectures. I'll try it on some of my corporate servers (solaris / linux ...) Having two timing modes would be a solution as you proposed. 2008/2/1, Siegfried Goeschl <[EMAIL PROTECTED]>: > > Hi Nicolas, > > a few thoughts > > +) I use dynamic proxies together with JAMon to measure the execution > time of method invocations - ns would make a lot of sense here > +) the execution times also depend on you JVM since you are using JRockit > +) and finally it depends how often you start/stop a monitor > +) retrotranslator will fail badly since System.nanotime() was > introduced with Java 1.5 > > Maybe the decision can be deferred until creating a monitor - the user > decides whether to use ms or ns? > > Cheers, > > Siegfried Goeschl > > nicolas de loof wrote: > > Hello, > > > > For commons-monitoring my first intent was to use System.nanotime() to > > compute code performances. A simple bench [1] demonstrates that > > System.currentTimeMillis is FAR quicker to return current time (on my > > windows box [2]) : > > > > nanoseconds precision may be usefull for profilers, but is it for > monitoring > > purpose ? > > > > > > > > [1] 10000000 time (System.nanoTime() ) vs (System.currentTimeMillis()) : > > > > D:\projets\apache\trunks-sandbox\monitoring\target>java -server -cp > > .\test-classes > > org.apache.commons.monitoring.bench.CurrentTimeMillisVsNanoTime > > nanotime took : 4683052742ns > > currentTimeMillis took : 26907938ns > > > > [2] > > D:\projets\apache\trunks-sandbox\monitoring\target>java -version > > java version "1.6.0" > > Java(TM) SE Runtime Environment (build 1.6.0-b105) > > BEA JRockit(R) (build R27.2.0-131-78843-1.6.0-20070320-1457-windows-ia32 > , > > compiled mode) > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
