Some users have noticed that LimeWire can take a while to hash shared files. Hashing is unfortunately a very CPU-intensive process. To prevent the hashing from consuming all the CPU, LimeWire actually does not hash files as fast as it could. Should we change this?

Chris:
I would rather have my client hashing slowly in the background so that I don't notice it.
If there was an app telling you
"Please wait. Your files are being hashed"
Then you would probably dont share or uninstall that program.
I think the way Gnucleus handles it is okay, actually I havent
really tried Limewire when sharing lots of files.

Leave it as is....

I'd rather have resources available for other tasks, while hashing continues in background... rather than sit with an unusable processor... waiting for hashing to complete!

No - it is good as it is.

Do you also limit the CPU usage on hashing a file that has just been downloaded?

I've noticed that whatever LimeWire does at the completion of downloading a file can make connections unstable - more so with large files (100s of MBs). It looks like LimeWire as a whole isn't getting enough CPU to process all the normal actions in good time.

Mark

Wouldn't it make sense to tie the amount of CPU usage for hashing filelists to the already present CPU choice for uploading files? If I am willing to devote 100% of CPU to uploads, I would also want to devote Max usage to the hash process and get it overwith. People with slower machines usually set CPU time for uploads a lot lower, and as such hashing could take a bit longer.

Personally, when I run the program, I want the hash list done as quickly as possible so I can start editing and annotating the recent downloads.

My 2cents worth

The only problem I have with the current hashing code is that your shared files aren't shown until they finish hashing. It's disconcerting and confusing not to immediately see what's shared -- I don't care that they're not immediately available for download.

Chris:
I don't share files over LimeWire so do whatever you think is best.

but Personally, I think that the hashing feature is fine in its current implementation. I do agree however that there should be some type of progress indicator-indicating the file that is currently being hashed and its percentage of completion. Perhaps there should be a message indicating that files are being prepared for sharing. I have a particularly useful recommendation for CPU utilization and file-hashing:

1. Set to default hashing to 50% of the CPU utilization.
2. Create an option in the configurations menu that allows a person to change-on-the-fly the speed in which the hashing is done.


The first option allows you to satisfy the users who are happy with the current implementation and "Out of the box" configuration would support this implementation.

The second option, would give users such as myself the ability to allocate 100% of my CPU utilization to hashing. because I run several servants and the files can range in size from 1 MB to 400 MB in size and these files are stored on a network file server-- hashing can take hours.

Hope this helps.

__________________
Lee Evans, President
LeeWare Development
http://www.leeware.com

Sometimes my computer crawls, cause I have 1GB sized files in my shares. The GUI becomes unusable, and I get impatient cause my other procs are affected, so I have no choice but to kill -9.

Might this be caused by not threading out the hash process?

I think I will just have to not share my files till this is resolved. If everyone had to do this, it would be a great loss for P2P.

With complete naivite' I will say that it appears as though the hash indexing mechanism is not optimized for/with multithreading.

-dch

I too would like to see a process indicator at the end of downloads. Sometimes it just seems to hang and that kind of worries me because I don't know if it's locked up untill it finishs. I would also like LimeWire to warn me if I try to close it whale it's hashing because I've done it at least once and you lose the download if you do that.