commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "nicolas de loof" <nico...@apache.org>
Subject Re: [monitoring] timing precision : ms or ns ?
Date Fri, 01 Feb 2008 18:20:31 GMT
I didn't commit from my office, but the bench looks like :

*

public* *class* CurrentTimeMillisVsNanoTime

{

*static* *int* *loops* = 1000000;

/**

* *@param* args

*/

*public* *static* *void* main( String[] args )

{

*long* time = System.*nanoTime*();

*long* t;

*for* ( *int* i = 0; i < *loops*; i++ )

{

t = System.*nanoTime*();

}

System.*out*.println( "System.nanoTime took : " + (System.*nanoTime*() -
time ) + "ns" );

time = System.*nanoTime*();

*for* ( *int* i = 0; i < *loops*; i++ )

{

t = System.*currentTimeMillis*();

}

System.*out*.println( "System.currentTimeMillis took : " + (System.*nanoTime
*() - time ) + "ns" );

}

}



2008/2/1, sebb <sebbaz@gmail.com>:
>
> And I could probably run it on OpenVMS
>
> ;-)
>
> On 01/02/2008, Siegfried Goeschl <siegfried.goeschl@it20one.at> wrote:
> > Hi Nicolas,
> >
> > if I either find the test code (or you commit it) I can tell you on Mac
> > OS X .... :-)
> >
> > Siegfried Goeschl
> >
> > nicolas de loof wrote:
> > > 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 <siegfried.goeschl@it20one.at
> > > <mailto:siegfried.goeschl@it20one.at>>:
> > >
> > >     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: dev-unsubscribe@commons.apache.org
> > >     <mailto:dev-unsubscribe@commons.apache.org>
> > >     For additional commands, e-mail: dev-help@commons.apache.org
> > >     <mailto:dev-help@commons.apache.org>
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message