Don't die tonight (the FrostWire projects needs your scrutiny, expertise, and support especially for licensing and international issues )

Seriously: your English tone may often be understood, but your ideas and contributions are always appreciated. I still think of you every time LW or FW has to hash big files--your optimizations there have been really effective. Thanks again

Could the posters on this site tell me what kind of files that they usually download? I am curious to see how others utilize this service. In two days I have yet to downlaod any file that I could use. It also ticks me off that purchasing a subscription from a supposedly games website was really a scam.

Don't worry, I'm not dead this morning. But that's not something I all always be able to decide myself.

What do tou mean there? that my English looks too much British? Or too much French? OR too difficult to understand from a native American English?

Note that the version bundled in LimeWire is not the latest. I have updated it several times, and in last spring I found other optimizations (and then discovered some processor caching issues, that caused additional processor cycles to be used for wait states, due to too many cache lines being used.

Compared to thecurrent version in LimeWire, the one thatis on www.rodage.org/pub/java has about 20 to 25% of speed improvement (also the sources there include other hashing algorithms, also extremely optimized for performance for the new standard hashes. However the benefit face to the JDK implementation is much less impressive, because thesealgorithms are more complex and need more registers when the internal JIT compiler in the Java VM compiles the bytecode to native code. You would find there the fastest impelmentations anywhere on the web, made in 100% pure Java, and that outperforms most commonly used C-written implementations.

None of them are in Limewire which has my first versions made about 1,5 year ago.

I could be faster, but I need to study how to dynamically generate a Java class directly with manipulating the bytecode (this is possible with BCEL) as the only limitations I can see now are caused by the Java compiler (and the Java syntax requirements) that does not allow swapping some statements (however the JVM has made significant progresses since version 1.4.2, so that the extra time caused by suboptimal bytecode generated by the Java compiler can most often be avoided at runtime by the JIT compiler, which is now extremely impressive in the way it can generate excellent native assembly instructions from the Java bytecode. The benefit is extremely visible for example in 100% pure Java classes that now can perform 3D animation, or handle realtime audio/video streams.

The other important benefirts in Java 1.4.2and 1.5 is definitely its new memory manager, the much faster garbage collector, the new unsynchronized classes for most I/O, the new multithreading scheduler, the internal refoundation of the JIT compiler with a more generic engine that can handle more registers and 64-bit architectures with smarter rules (including the use of MMX/SSE/SSE2 instructions if present, for 64-bit computing in 32-bit mode; also many benefits frome from the newer Java2D API which interacts cleanly with DirectX on Windows and so can use hardware acceleration for display of the various elements of the Swing interface; as well, Swing is now much more optimized. And there are lors of optimizations in Java 1.5 regarding the internal APIs that allow reusing direct buffers or that allow computing with platform native buffers without additional copies or transforms). Overall, this has helped LimeWire a lot.
Bit Limewire itself was enhanced with faster internal processing, and with smarter management of internal priorities and worker threads.

__________________
LimeWire is international. Help translate LimeWire to your own language.
Visit: http://www.limewire.org/translate.shtml