There is an unsaved comment in progress. You will lose your changes if you continue. Are you sure you want to reopen the work item?
Allow a way to specify upper limit of # threads used for compressing
I do love this library! It took very little time to get a utility up and running. By the way, is the DLL threadsafe? If I call t a dozen times from my own threads will it work correctly? I assume so.
While I appreciate the use of multiple threads, it actually becomes a problem when used on servers. I am currently using it on a SQL Server machine with quad cores, and it maxes out all four cores. Obviously this is ... an issue. I am about to upgrade this
server to one of those 8 or 12 core AMD procs and I truly do NOT want DotNetZip grabbing all 12 cores for compression. If you think about it, moving from 2 to 3 cores gives you a 50% speed bump (all else equal). Moving from 7 to 8 cores gives you only a 12%
speed bump. Much less noticible or useful
My suggestion would be to give us a property to set the max threads. Then I could decide how many cores I want used for the zip operation.
By the way, I spent the weekend zipping up 200 gigs of stuff using the utility we wrote (using DotNetZip) and for my stuff got about an 80% compression. LOTS of room saved. Further we integrated DotNetZip into a process I run that exports huge SQL Server tables
to CSV and imports back in the processed CSVs. These table processes leave behind gigabytes of text files that I need to archive (can't just delete) and now I am getting about 80% compression on those as well.
Again though, Kudos on what you have done! Really cool!