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
 

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.

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.

>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.

i believe the newest version of limewire has two extra download statuses ... instead of sitting at 100% progress and downloading from 0 hosts, it will first say "Verifying File Contents" (and the progress bar will rise from 0 - 100) and then "Saving File". the first is for while it is hashing the file, the second is for when it is either moving or copying the file from the incomplete to the saved directory.

this lets you know when downloads are hashing.

More to my tastes would be to allow the user to choose, as one option defiantly won't fit everyone.

In my case, I'm running LimeWire on a machine that sits between my LAN and the internet (proxy server), and that's basically all it does. I'm sharing 40+ GB of data, and whenever it has to hash a file (median size is 160MB), it takes a long time... Longer than I would like. Worse, I've noticed that if the file is in the middle of the share directory structure, it will seems to stop searches from finding files further down in the directory structure (RedHat 7.3).

I wouldn't mind being able to flip a toggle, or slide a slider between 33% and 100%. I'd even go so far as to suggest 33-50% highlights in black, 50-75% in green and 76-100% in red.

Hes right
 

What the Guy above me posted is a very good idea,Ares has already implemented it,I have a pic atteched at the bottom:)

Simple is always best
 

The more choices you give the user, the steeper the appearance of the learning curve and the greater the need for proper documentation to explain the whole system. I favour leaving this aspect alone. Hashing is often quite slow because I rarely have Limewire standing alone but once you learn not to mess with it once it has started, I just get on with other things until it has finished. I don't think this aspect is broke enough to need fixing.

IMO the background hashing works good enough in the current version (2.9.8). It shows you "1/200 Files Shared" when it starts the hashing, and the Library view shows unhashed (hence unshared) files in red.

I notice the slow down after limewire hashes 500 + files. I just want more memory management for this enviroment. I would like to share 2500 - 5000 files easily but I really can't at this point.

Re: Simple is always best
 

I Agree With LeeWare And Believe there Should be options to change the hashing priority rather that a pre-defined rate.
But As David Said

It Could Confuse the users, So how about This :
1. The hashing priority is selected as the way it currently is. But you can select the hash priority to be higher and a short description about the priorty you selected would appear So people can make a informed decision

How about having LimeWire detect whether someone's computer has been idle for a while (5 to 10 minutes) and base the hashing speed on that? When the computer is actively in use by the user, slowdown the hashing speed so the user wouldn't notice a major slowdown when using other apps on their machine, but when the computer has been idle for 5 to 10 minutes, ramp up the hashing speed to full speed. When the user comes back and starts using their computer again, slow the hashing speed down again so it wouldn't affect the performance of other programs running.

Some Good Ideas Regarding Hashing
 

Actually, I think the previous posters idea is a pretty good one. there's a simple way to implement exactly what he's talking about. You could use a methodology commonly used in the distributed computing whereas the application uses the computers idle cycles to do it's hashing. obviously, you have to post a message at the beginning of hashing to indicate to the user that the hashing process is using the idle CPU cycles. otherwise, most users will freak out when they see their CPU pegged at 100%. On second thought, they'll freak out anyway if they don't understand what it means to use the idle cycles to do the hashing.

Finally, I think the current implementation is just fine.