In the tests I did (including compression of an entire filesystem image), xz always compresses better for the same effort (amount of time).

One example (using the standard tools, not the multithreaded ones):

  igorhvr:tmp/ $ ls -la co_2011-08_import.mdb*
  -rw-r--r-- 1 igorhvr igorhvr 261832704 2011-10-11 07:19 co_2011-08_import.mdb
  igorhvr:tmp/ $ sudo time nice -n -20 bzip2 -k co_2011-08_import.mdb
  42.85user 0.14system 0:43.16elapsed 99%CPU (0avgtext+0avgdata 31968maxresident)k 112inputs+0outputs (3major+2268minor)pagefaults 0swaps
  igorhvr:tmp/ $ sudo time nice -n -20 xz -3 -k co_2011-08_import.mdb
  30.99user 0.19system 0:31.48elapsed 99%CPU (0avgtext+0avgdata 130640maxresident)k 96inputs+0outputs (2major+8389minor)pagefaults 0swaps
  igorhvr:tmp/ $ ls -la co_2011-08_import.mdb*
  -rw-r--r-- 1 igorhvr igorhvr 261832704 2011-10-11 07:19 co_2011-08_import.mdb
  -rw-r--r-- 1 igorhvr igorhvr  24020243 2011-10-11 07:19 co_2011-08_import.mdb.bz2
  -rw-r--r-- 1 igorhvr igorhvr  23949408 2011-10-11 07:19 co_2011-08_import.mdb.xz

In this case xz compressed roughly to the same size (slighly better than bzip2, actually) using only 72% of the time. This is often the case.

Interesting I may have been comparing parallel bzip2 with single threaded xz or perhaps it was just the data I was using for a test.

I'll have to look at it again, thanks!

Put two spaces before your lines of terminal output to prevent HN from munging them.

Done - thanks