[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: plzip: manual gives very false numbers, real defaults are huge!
From: |
Steffen Nurpmeso |
Subject: |
Re: plzip: manual gives very false numbers, real defaults are huge! |
Date: |
Thu, 09 May 2024 00:06:46 +0200 |
User-agent: |
s-nail v14.9.24-621-g0d1e55f367 |
Hello again Antonio.
Antonio Diaz Diaz wrote in
<663B9C7A.9010401@gnu.org>:
|Steffen Nurpmeso wrote:
|> #?0|kent:plzip-1.11$ cp /x/balls/gcc-13.2.0.tar.xz X1
|> #?0|kent:plzip-1.11$ cp X1 X2
|> [...]
|> -rw-r----- 1 steffen steffen 89049959 May 7 22:14 X1.lz
|> -rw-r----- 1 steffen steffen 89079463 May 7 22:14 X2.lz
|
|Note that if you use uncompressible files as input, you'll always obtain
|similar compressed sizes, no matter the compression level or the diction\
|ary
|size. Try the test with gcc-13.2.0.tar and you'll see the difference. \
|(As in
|your other test with /x/doc/coding/austin-group/202x_d4.txt).
|
|> I think dynamically scalling according to the processors, talking
|> into account the dictionary size, as you said above, is the sane
|> approach for "saturating" with plzip, in the above job there are
|> quite a lot of files, of varying size (the spam DB being very
|> large), and one recipe is not good for them all.
|
|Maybe there is a better way (almost optimal for many files) to compress \
|the
|spam DB that does not require a parallel compressor, but uses all the
That was only an example, that is a single bogofilter lmdb text
dump, perfect for your default algorithm.
|processors in your machine. (And, as a bonus, achieves maximum compression
|on files of any size and produces reproducible files).
|
| ls | xargs -n1 -P4 lzip -9
|
|The command above should produce better results than a saturated plzip.
|
|'ls' may be replaced by any way to generate a list of the files to be
|compressed. See
|http://www.gnu.org/software/findutils/manual/html_node/find_html/xargs-o\
|ptions.html
Yes, thank you.. but no, then i would simply ()&, save away the
$!'s and wait(1) for them, in this case. I find the adaption
compression of (p)lzip still very satisfying (all this started up
with gzip quite long ago, i think (arj back in the 90s on 4DOS
/ Windows 95B, in fact)).
|Hope this helps,
|Antonio.
Oh, i very much like your plzip! Thank you very much. lzlib too
but for the malloc()s 8-)
--End of <663B9C7A.9010401@gnu.org>
I wish you a good time, dear Antonio.
Ciao from Germany,
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
- plzip: manual gives very false numbers, real defaults are huge!, Steffen Nurpmeso, 2024/05/04
- Re: plzip: manual gives very false numbers, real defaults are huge!, Antonio Diaz Diaz, 2024/05/04
- Re: plzip: manual gives very false numbers, real defaults are huge!, Steffen Nurpmeso, 2024/05/04
- Re: plzip: manual gives very false numbers, real defaults are huge!, Steffen Nurpmeso, 2024/05/04
- Re: plzip: manual gives very false numbers, real defaults are huge!, Antonio Diaz Diaz, 2024/05/06
- Re: plzip: manual gives very false numbers, real defaults are huge!, Steffen Nurpmeso, 2024/05/06
- Re: plzip: manual gives very false numbers, real defaults are huge!, Antonio Diaz Diaz, 2024/05/07
- Re: plzip: manual gives very false numbers, real defaults are huge!, Steffen Nurpmeso, 2024/05/07
- Re: plzip: manual gives very false numbers, real defaults are huge!, Antonio Diaz Diaz, 2024/05/08
- Re: plzip: manual gives very false numbers, real defaults are huge!,
Steffen Nurpmeso <=
- Re: plzip: manual gives very false numbers, real defaults are huge!, Steffen Nurpmeso, 2024/05/07
- Re: plzip: manual gives very false numbers, real defaults are huge!, Steffen Nurpmeso, 2024/05/07
- Re: plzip: manual gives very false numbers, real defaults are huge!, Antonio Diaz Diaz, 2024/05/08
- Re: plzip: manual gives very false numbers, real defaults are huge!, Steffen Nurpmeso, 2024/05/08
- Re: plzip: manual gives very false numbers, real defaults are huge!, Steffen Nurpmeso, 2024/05/07