It looks like the dominating factor in the crypto in authorizeTime is BigInteger.modPow() (a JVM-provided method, which really ought to be fast...). I'm seeing an average time for modPow() of 1412ms (it seems to be increasing...). With Sun 1.4.
Now, with Kaffe, which uses libgmp, averages are closer to 59ms-75ms. I will run it on Kaffe overnight to see what happens. Possibilities: A) Fix remaining Kaffe problems (kaffe has monolithic GC, causing longish delays from time to time which lock the whole VM, but there is a kaffe derivative that uses Boehm incremental GC which could be merged; kaffe seems to get longer lock times suggesting maybe its locking is very heavy...), bundle Kaffe with Freenet (even on the Win32 version - this should be possible, I believe there is a port). Grumble if running a Sun JVM, but still run. B) Call out to an external, platform specific helper app if available (grumble loudly if it isn't there). With times of a second or more, this is probably still faster than using Sun's slow code. C) Any other suggestions? We really should do something about this is 0.5.2 - shaving 900ms off average authorizeTime's/connectingTime's is not something to be ignored. BTW, the theory: Kaffe uses libgmp, which is very very fast. Sun uses some apparently badly written in-house BigInteger code. -- Matthew Toseland [EMAIL PROTECTED]/[EMAIL PROTECTED] Full time freenet hacker. http://freenetproject.org/ Freenet Distribution Node (temporary) at http://80-192-4-36.cable.ubr09.na.blueyonder.co.uk:8889/J3Q~LkZ7ezk/ ICTHUS.
pgp00000.pgp
Description: PGP signature
