Perhaps the author has never used Mac or Linux, else he wouldn’t be “sorry.” These real operating systems have command line compression utilities readily available.

two things to consider: you’d expect the compression level to go up and speed to go down as you went up the ranks, yes? In a reasonably linear way? Also, as far as i’ve heard, BZip is the most modern method.

Running them just long enough to get reasonable ideas of the compression level and speed, then cancelling. Default settings used again, except for 2 threads to make better use of my dual core.

“Maximum” (ultra minus 1) level, Bzip: By the time it got to 1%, it had taken over 1 minute and had produced 40mb of output.. for 40mb of input. Not good.

“Ultra” level, LZMA: 2% reached in about 25 seconds, and 1.1 mb output for over 100mb of input, estimating 20mins total. Would probably result in that same 26mb file, but at 35% better speed. Which isn’t exactly double, but it’s a nice bonus, better than WinRAR, and shows it is genuinely using the second core whilst having to make way for I/O, system calls etc.

“Ultra” level, BZip: It’s been running more than 3 minutes and still hasn’t reached 1%. Output size currently at 39mb for 39mb input. Argh. It even took about 10 seconds to complete “cancelling”.

“Maximum” level, LZMA: similar results to Ultra. Maybe slightly faster and slightly less well compressing but not by any significant margin in the first few %. (The way it runs through the file list means that this is actually a decent predictor of final result, give or take 5% of the figures).

“Ultra”, PPMd: Dual core NOT an option. Compresses by a moderate amount (approx 66% of original size) and predicts about 1h 45m packing time. 1% arrives in 1m05 and leaves 33mb output for 48mb input. Oookay.

“Maximum”, PPMd, for completeness: finally gives the expected “slightly faster, slightly less efficient” result. Which in this case means about 90 minutes and output at about 75-80% of the original. Rubbish, in other words.

TAR, for utter completeness: Absolutely rockets along, as you’d expect. Hits 50mb/sec at one point before the disk starts to complain and backs off to the low 20s. Estimated time at 50% is under 4 minutes. So I guess it could make for a good way of quickly bringing a lot of tiny files together to dump on a slow-access (but fast raw R/W) device in linear mode. IF you don’t have any better backup program, e.g. something that was bundled with it. But it’s not e.g. 2x as fast as the USB drive, and I doubt copying things to it linearly would be either, meaning it’s still slower than just copying the stuff across in the first place. And of course the output is 1:1, but at least this format has an excuse!

So it would actually seem the absolute default settings are possibly the best (without spending further hours playing with dictionary sizes and other ephemera), which is a positive thing. However, why are all the other ones there? And if BZip IS the latest and greatest, why does it perform no better than TAR (but a whole lot slower)? And how come Ultra is often faster than Maximum? (I suspect it, and only it turns on Solid mode, which can have speed as well as size benefits… but 5x speed? That’s just crazy).

Maybe not one for users who like to fiddle with buttons without considering that buttons tend to change things, then. We all know the type…. give ‘em WinRAR or possibly even WinZip free version instead.

first impressions: WinRAR unpacking speed quite good, 24mb/sec onto the same spinning disc (unknown speed but no higher than 7200rpm/SATA150) as the archive is being taken from – 3m15 in total. 7Zip noticably faster, over 31mb/sec, needing only 2m30. Pretty good, but it’s not a difference that makes me go “wow” – dealing with archives this large is rare, and the overall difference is small, particularly for something you would leave in the background. It would, however, be useful if you were e.g. wanting to extract a single folder from the middle of a monstrous, multipart “solid” backup. (Of which I do have a couple of >10Gb examples, from attempting to help the geocities rescue project)

WinRAR repacking not as swift, but very easy to set up; most gory settings are hidden from the user and default to “autodetect”. Select the folder, name the archive, select RAR, Maximum compression, Solid, and decline to tick for SFX, error correction or password protection. Compression took about 22 minutes and produced a 26.8mb file (told ya it was extreme), with it flying through the duplicated files too fast to read.

7Zip: OH GOD THE OPTIONS MY EYES. No autodetect for anything and pile of confusion technical tweaks right there in your face, no “wizard” (that I can see as an obvious button or menu option) or simple mode available. What compression method should I choose? Dictionary size? Word size? Solid block size? Number of CPU threads? Arrrgh. (And that’s me as a fairly anoraky geek coming to it cold)
I left everything at the default after choosing Filetype-7Zip and Compression Level-Ultra. It took 27 minutes to produce a 26.0mb file, after estimating halfway that it was on course for a 27.5mb one. So it’s slightly more efficient, in terms of its output being 97% the size of an already outrageous crunch, but actually slower despite being offered to me as a faster compressor.
It also gave me the option of packing these files as Zip (which failed under WinRAR as the total file size was “too big”, I assume >2Gb). I again chose Ultra and the defaults. It started work, but I cancelled before finding out if it would end up hanging at 2Gb because a/ it was incredibly slow, estimating almost 2 hours to pack (on a 2.1Ghz Core 2 Duo with 3Gb), and b/ it wasn’t actually compressing the data; after processing about 200mb, a point at which the other two were already producing substantial size savings, Zip had made a *completely uncompressed file*.
It also offers Tar format. I cannot fathom why. For people making Linux installer packages who don’t like the actual Tar utility?

Now to see how 7Z and WinRAR fare at unpacking speed with 7z format files…

Both extract using the two archivers’ respective shell-integration “extract here” menu button.

7Zip itself: an impressive 2m10s, which is probably as fast as this hard disk can support. I think it must have used a hell of a lot of memory though (forgot to monitor for that) because the system practically hung up for 10+ seconds afterwards with the hard drive thrashing, presumably freeing up a load of virtual memory.

WinRAR: started well, depacking quickly and quietly and on course for a sub-2 minute time. then the disk started to thrash and it slowed. hmm. eventually clocked in at 2m05 with some of the residual disk activity as before, but more spread out and less intense – so that I was still able to operate the PC whilst it continued.

Possibly there’s elements of the disk’s fragmentation etc involved here (shouldn’t be – it’s 160Gb with about 50% free and recently defragged, plus I’m deleting any testfiles that aren’t needed before starting the next part), but taking this at face value WinRAR actually depacks 7Zip files both faster than 7Zip itself, and quicker than either of them depack RARs. Odd.

For comparison I also copied the unpacked fileset off onto a USB disk (1Tb, NTFS) and back to see how quickly it could read. Sadly the interface ruined this… I’m still waiting on an ordered eSATA-300 unit (replacing a stolen one) to arrive which should help, but today the best I could get was about 6m20 copying off the main HD, and 4m40 copying back on (12.5 and 17.0mb/s respectively, not even near the best I’ve seen for the external drive – but then the biggest file copied is only 1mb…). So all that can be said is that both archivers stress the disk when depacking more than a straight copy from an external USB HD can

Thus far, I’m not entirely sold, but I’m not turned off either. Strange ambivalence. I’ll probably stick with WinRAR because that’s what I’m used to and what I know how to get the best result from – plus with this fileset at least, it’s slightly quicker to compress and only very slightly (3%) less efficient on size… when both packers crushed the files by over 150x! However for things where I may be having to pick a handful of files out of a large, solid, moderately compressed (say, ~50%) archive, I would consider using 7Zip; an extra 10 minutes or so on the compression side may only save 1mb out of a 12Gb fileset, but it would pay off massively on later extracting and depacking. However… need more datapoints to be sure.

OK, you’re not supposed to keep using past the 40 day limit… but we all do. Maybe if it was for corporate use I would?

I’m not shilling for them here. I’ve just got a few people including on this thread trying to get me to switch and I can’t see why. I’m poised to install it having finally convinced their site to give me the setup file, just as soon as my own benchmarking run with WinRAR is complete. Might then come back and say whether I’ve been converted or am still skeptical.

For personal archiving you can then use the 7z for greater compression. 7zip also supports command line instructions, and supports split files. Taking all of its abilities and knowing that its completely free makes it 10 times better than winzip and winrar. There is very little that the shareware programs can do that this freeware one cant.

7zip is a very worthwile tool to install.

I prefer to 7-zip. If you are not sure about which uncompressor the other one is using, you can compress the files with zip format. 7-zip provide two compressing opinions in context menu, one for 7z, one for zip, at the same time.

If you had looked at the sourceforge project page ( http://sourceforge.net/projects/sevenzip/ ) or at the creators homepage ( http://www.7-zip.org/ ) instead of some random website named alike, you would see that not only Linux and Mac are supported but also many other platforms are able to use 7-zip.

Also the random website you linked points to older version of 7-zip (hosted at sourceforge, but who knows when the page creator will change that link to some virus ladden file).
–

Other than that great post

FAIL.