Shareaza super-slow when scanning/processing large library

[cadetstimpy]

I'm running Shareaza v2.5.1.0 on Windows 7. When I first loaded Shareaza, I pointed the Library to a small music directory (about 300 files), and it scanned/processed the files relatively quickly (I'd say less than a second per file). When I added all my music (160,000+ files), the scanning/processing slowed down to about 3 minutes per file! That was with the hashing set to "faster". I even upped the priority of the Shareaza process in the Task Manager to above normal, but it's still super-slow. Interestingly enough, ShareazaPlus was able to scan my entire Library in under 2 days, but at 3 minutes/file, Shareaza is going to take months to process all the music. What's up with that?

I have a 3GHz quad-core CPU with 8Gb of RAM.

Mike

[ocexyz]

[cyko_01]

upping the priority of the Shareaza process in the Task Manager will not make a difference, but what you can do is click the "hash faster" link on the home tab(hashes at 10X the speed by default). If you are in power mode you can also change the advanced setting "Library.HighPriorityHashing". With a system as fast as yours you should be able to increase this value significantly without slowing down your system

[diztrancer]

This is not Windows 7 related issue.

What version u use ? It may be related to Multi-Core CPU
U have 8GB of RAM - so u use Windows 7 x64 edition ?

Try to use Shareaza 32bit on W7 x64.

P.S. for OCE : assume that Windows 7 is Windows 2000 SP11.

[cadetstimpy]

Thanks for the replies.

ocexyz: My disk is 0% fragmented.

cyko_01: I was using "fast hashing".

diztrancer: Yes, I'm running Windows 7 Ultimate 64-bit, and Shareaza is the 32-bit version. Is there a 64-bit version?

Mike

[old_death]

Yes there are 64 bit builds available on the debug builds page. The latest one is: Shareaza_2.5.1.1_x64_Debug_r8410_2009-12-23.exe

[branko-r]

I noticed this problem too. First entries are added to the library fairly quickly, and then it gets progressively slower, to the point of being barely usable.

My guess is the following: the library works in such a way that the time required to add a file to it is (at least!) directly proportional to the number of files in it already. This would mean that creating a 200,000-file library will be 100x slower than creating a 20,000-file library (instead of just 10x slower, what one would expect in an ideal case). Actual size of files being added is more or less irrelevant here - it's the number.

Prior to Shareaza, I used BearShare, and its library facilities were fairly good: it was possible to maintain a 100,000-file library on a 512 Mb machine. While it wasn't too quick, it worked. I wouldn't even attempt this with Shareaza.

However: this is probably far from trivial to fix, and it could well be argued that this is an excessive size for a library.

[ocexyz]

Perhaps some wastes remain in memory and should be flushed before next hushing?

[cyko_01]

[branko-r]

[ocexyz]

[kevogod]

I tried the 64-bit debug version old_death mentioned (Shareaza_2.5.1.1_x64_Debug_r8410_2009-12-23.exe), but it was just as slow as the 32-bit v2.5.1.1 regular version.

Mike

[old_death]

I had hoped this would speed it up a bit...

I suspect the problem lies in the library handling. It seems not to really scale well according to your reports...