-----Original Message-----
From: boblusebob@aim.com
To: charlie.groves@gmail.com
Sent: Sat, 24 Nov 2007 2:56 am
Subject: Re: [Jython-dev] Jython Clock Resolution

Hi Charlie,

Well it looks like I've been removed from the Jython project to submit problems in Tracker, probably because I just sort of appointed myself a tester for Jython 2.2 because I was testing my own Jython socket programs at the same time that 2.2 was coming out.  I'll submit a problem if I get access.  For this case, I have just been doing a lot of time resolution stuff and saw that this change could be made relatively easily.

My script though is very simple and basic.  I would expect to see about 15 millisecond resolution before the change to using nanoTime and about 25 microseconds resolution after the change on Windows XP, of course actual mileage will vary depending on road conditions, etc.  I think the test is clearly accurate enough for the conditions and for the nearly 3 orders of magnitude resolution improvement for time.clock() that this change should make.

The script is as follows:


mport time

values = []

for i in range(100):
    t1 = time.clock()
    t2 = t1
    while t1 == t2:
        t2 = time.clock()
    values.append(t2 - t1)
    #print (t2 - t1)
print 'Average resolution for time.clock() is: ', ((sum(values) / len(values))*1000), ' ms'


If you have any questions on this script let me know.  If I am doing something wrong that is causing me not to be able to open problems for Jython, let me know that as well.

 - Bob

-----Original Message-----
From: Charlie Groves <charlie.groves@gmail.com>
To: boblusebob@aim.com
Cc: jython-dev@lists.sourceforge.net
Sent: Fri, 23 Nov 2007 9:14 pm
Subject: Re: [Jython-dev] Jython Clock Resolution

On Nov 23, 2007 3:33 PM,  <boblusebob@aim.com> wrote:

> Thank you Charlie. You of course are right about time.time(). It couldn't

> be improved using nanoTime. Time clock should be relatively easy though and

> should improve things by quite a bit. I will put my example scripts

> together with a naive first pass at a solution and open a problem.

It's a pretty simple change, and I think I've already got it in my

local copy. If you just want to create a bug and upload the example

script, that'd be good. I was just hoping to test against your

expectations before committing it.

> I imagine Python uses getTimeOfDay() on unix like systems for time.time().

> time.time() could could still be improved using JNI and getTimeOfDay() on

> Unix like systems and then Jython's resolution would basically match Pythons

> (since Pythons Windows XP resolution for time.time() really isn't any better

> than Jythons). I understand that it isn;'t quite as simple of an

> enhancement though to use JNI. Does/would Jython consider using JNI and c

> for time.time()?

Since the docs don't promise anything better than second resolution

for time.time, I don't think it's worth the headaches of JNI to

provide better resolution from time.time. There's some talk of using

JNA to provide easier access to native functionality for things that

don't have a counterpart in straight Java, so if that lands it should

be easier to do this sort of thing.


Check Out the new free AIM(R) Mail -- Unlimited storage and industry-leading spam and email virus protection.