Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: domain of nicolas.deloof@gmail.com
 designates 72.14.214.235 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth;
        b=rWBMMriATIkhN8fyzHf1wzbtFlp0AzO7iapVJXywT5xGR1W5GKcruxTsg1S1TfnLZe1AgGHnzsHcsl77SDh45TxUtThu/xy9/JoGypae/tFyNjVKYWF2aXqcHQBcwS30u5odKsBmAkmMtzQRsOGtObfFimR/cJZ/4en8eppQXyE=
Message-ID: <4c39e3030802011023s6074fd87s8aa95082818778aa@mail.gmail.com>
Date: Fri, 1 Feb 2008 19:23:07 +0100
From: "nicolas de loof" <nicolas@apache.org>
Sender: nicolas.deloof@gmail.com
To: "Jakarta Commons Developers List" <dev@commons.apache.org>
Subject: Re: [monitoring] timing precision : ms or ns ?
In-Reply-To: <4c39e3030802011020p75605995l2fc5d1e376d87f2c@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_30674_17045942.1201890187610"
References: <4c39e3030802010650k44c81f44y2d6a8bb576ce4456@mail.gmail.com>
	 <47A33660.6000707@it20one.at>
	 <4c39e3030802010816s66d194b1n4174a9a8b295e30@mail.gmail.com>
	 <47A34A03.50408@it20one.at>
	 <25aac9fc0802010846p61a058cl520688fa8ebfee2@mail.gmail.com>
	 <4c39e3030802011020p75605995l2fc5d1e376d87f2c@mail.gmail.com>

------=_Part_30674_17045942.1201890187610
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

and without stupide copy/paste colorde formatting :


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, nicolas de loof <nicolas@apache.org>:
>
> 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
> >
> >
>

------=_Part_30674_17045942.1201890187610--