On Mon, Sep 15, 2003 at 01:52:17AM +0100, Jonathan Howard wrote:Not necessarily - depends on the JVM - this is often a native call which, therefore, has a significant overhead anyways. In cases where it is a native call, you're reliant on efficient time-related functions - in a number of cases these methods are known to be slow.
I'm new to looking into the Freenet code and haven't got the full picture of workflow, but I know it isn't pleasant.
The good news is I'm running with Windows ME MaxConnections set to 256 and freenet's max connections up to 128 without any additional bugs.
I assume you are using the current version, 6193? Anonymous CVS is
pretty old. Get the current unstable source tarball from
http://freenetproject.org/snapshots/
The squeamish should close their eyes now.
I've been trying out a profiler, seeing what it would pick up. It was counting waits so lead me to the following code.
BlockingQueue (the tabs are messed up in my changed version)
Half a dozen bugs and the potential to crash Java. You can't go blaming sun for the spec without a suitable alternative, (many have tried). See
Hrrm? What bugs?
attached TimeTime.java for one of the unwritten limits of timing capability.
Are you saying the profiler said that System.currentTimeMillis() is significant? That's a profiler bug IIRC, caused by it being such a short method.
In the case of Linux the native method looks like:
timeval time; int status = gettimeofday(&time, NULL); ...... return jlong(time.tv_sec) * 1000 + jlong(time.tv_usec / 1000);
gettimeofday is not optimized on many platforms (including Linux until the 2.4 kernel, I think).
<snip>
Dan.
-- Dan Creswell [EMAIL PROTECTED] www.dancres.org
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
