Sharing very slow at every startup?

Hello,

I'm sure this has been answered before, I took a look with the search engine but didn't find anything really obvious.

Right now I'm only sharing about 100 songs since I just bought limewire pro (using LimeWire Client 4.0.2 pro).

Every time I startup, there's a ~10 minute delay as I watch the text at the bottom telling me "Sharing 1/100, then 2/100, then 3/100", etc... files. During this time I'm unable to use my computer to play music or do much of anything because the CPU is working like crazy.

I've heard the concept of hashing here, but don't really know what it means. I saw a reference to someone who mentioned that files shouldn't be "rehashed" on every startup - is this what is happening to me? In my sharing directory I don't see any files other than the music files - should I? I'm using a different folder to share than the default, e:\mp3\lime , though I doubt this would make a difference.

Thanks!

[stief]

Once it gets to 100/100, the hashing will be finished. This can take quite some time (it's really painfully long for old java clients like in Mac OS 9).

The drive *shouldn't* matter . . . you could just test by copying the \mp3\lime folder to the same drive as your LW app and see how long it takes to hash if you share it from there. If the drives don't matter then it will take the same amount of time.

btw--hashing, as you correctly noted, is very CPU intensive. On a quick machine, it takes about 10 minutes to hash 1 GB. Each file will now have a unique ID, so that if even 1 bit changes, the file will have a different hash. This allows files (and even parts of the file) to be securely shared. Once done though, the results are saved in the fileurns.cache preference file, and don't need to be repeated on each startup.

cheers--happy sharing

[verdyp]

Note that I have worked on accelerating the SHA1 hashing. I hope that LimeWire will test the new SHA1 class I created, because it DOUBLES the performance of the SHA1 "MessageDigest" so that, for the same CPU time, it will hash twice the volume.

However it will require testing it on other platforms than just mine (Windows), notably on MacOSX where some optimizations that are perfectly legal according to the Java VM specification produce errors when computing expressions.

The new code I created should however be extremely beneficial to Mac OS 9 users, because it avoids all memory management (which is shamely one of the main causes of slow performance in Java 1.1.8/MRJ 2.5, the latest supported Java on Mac OS 9).

Give us some time to beta-test this SHA1 hashing code completely, and it may be in a later release of LimeWire. (On my PC, an Athlon 1800+ XP on Windows XP with Java 1.5-RC1, this code can hash 47 Megabytes per second, instead of 22 Megabytes per second with the default hash implemented in Java core libraries; the difference of performance is even greater with Java 1.4 or 1.3, where my code works roughly at the same level of performance, unlike the default code in Java core libraries).

---

Hashing should not take 100% of your CPU. It is limited on purpose so that its background-running thread will not take more than 33% of the total execution time, leaving enough time to keep the LimeWire GUI or your other apps responsive. At most, LimeWire should not take more than 50% of your CPU time when connected, unless you are trying to download lots of files in parallel.

That's one good reason why the number of concurrent downloads is limited: if it was unlimited, we could have hundreds or thousands of threads taking all your CPU if they all try to connect to various sources, accessing to complex data structures for each file and each source. You can choose the number of concurrent downloads to authorize in the options (you can still select more files to download but they will be queued locally, and tried one after the other).

If you have poor performance, you may need to reduce the number of concurrent downloads allowed in the options panel.