![]() |
hashing speed 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. |
Don't steal the CPU! 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 |
Hashing things out 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 |
show unhashed files... 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. :D |
Re: hashing speed Quote:
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. |
Problem with Shares in LimeWire 2.7.X.... Hashing / Indexing / Threading? 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. |
All times are GMT -7. The time now is 11:34 AM. |
Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2025, vBulletin Solutions, Inc.
SEO by vBSEO 3.6.0 ©2011, Crawlability, Inc.
Copyright © 2020 Gnutella Forums.
All Rights Reserved.