If you use the compression on the dynamic link liberies
and the main executable file your app will have an
performance increase and smaller download and
less memory consumption for users. It
will also help to curb reverse enginering

Just a little idea..

If anyone here has a copy of these special compression
tools for programmers they will know what i am on
about. I found a performance increase already.
(not a line of your code is edited, its simply
a nice optimization process)

Upx Download here

http://upx.sourceforge.net/#download

UPX is a versatile executable packer with the following features:
excellent compression ratio: typically compresses better than WinZip/zip/gzip, use UPX to decrease the size of your distribution ! very fast decompression: ~10 MB/sec on an ancient Pentium 133, ~200 MB/sec on an Athlon XP 2000+.
no memory overhead for your compressed executables because of in-place decompression. safe: you can list, test and unpack your executables. Also, a checksum of both the compressed and uncompressed file is maintained internally.

Quick tip.. Copy the upx.exe in the program directory, goto
the dos prompt and type upx *.dll

Upx cannot the program exe for this software, though
normally you can.

So to maximize the process or if you want a commercial
alternative to do dll's and exe's use Aspack

Asp Pack

http://www.snapfiles.com/get/aspack.html

ASPack is an advanced Win32 executable file compressor, capable of reducing the file size of 32-bit Windows programs by as much as 70%. (ASPack's compression ratio improves upon the industry-standard zip file format by as much as 10-20%. and it
requires no unzipping!)

LimeWire is written in Java.

Its only partly written in java.. what drives the
front end is executables and liberies

ie check your install directory

limewire.exe
genericwindowsutils.dll
limewire20.dll
windowsv5plusutils.dll

What drives the front end is Java code. LimeWire.exe is a rewritten "javaw.exe", and those dlls are just stub helpers, to allow LimeWire to do OS-dependent stuff, like getting the system idle time, or setting a file to be writable, etc. There's about 100 lines of C code (if even that) and hundreds of thousands of lines of Java code.

So far I've only read nonsense except for "written in Java" in this thread. Continue, please.

Also, we're not trying to obfuscate anything. LimeWire is 100% open source. See http://www.limewire.org .

dont take it personal.. everyone likes
to tweek for a little more speed.. just thought it
might help - beta programs are supposed to
be about that sort of feedback. I am not disrospecting
your code.

Er, who took it personally? "I_Have_No_Account" doesn't work for LimeWire -- I dunno who they are, they have no account.

Optimizing C code will have little to no effect on LimeWire, since barely 0.5% of LimeWire uses C code.

UPX doesn't make any program faster. The only point of UPX is saving disk space. However, unless you're talking about small portable removable media, the size of your programs is completely unimportant. You won't save a bit of RAM through this. The decompressor takes some overhead, even if it's just a little. The decompressed executable must be kept in RAM or paged to disk. This is unnecessary with an uncompressed executable because it is already on disk. So where's the significant advantage? I don't see one.

As far as I know, Java bytecode is compressed anyway and even if you saved a few percent of RAM by UPX, the amount of memory used by the Java VM ridicules that effort.