探検
【gzip】圧縮対決【bzip2】
■ このスレッドは過去ログ倉庫に格納されています
http://www.quicklz.com/
quicklzより良さげなのにクローズドソースのlzturbo
http://consultant-berater.de/lzturbo/
圧縮率かなり高いけど相当遅いPAQ
http://cs.fit.edu/~mmahoney/compression/
http://www.haskell.org/bz/
PCの性能は十分あるんだし
誰かに渡すファイルはgzとかbz2にしてる。
ttp://www.maximumcompression.com/data/summary_mf3.php
OpenVPNで使ってるLZOしか知らなかったけど、THOR, QuickLZ, LZTurbo, LZO って同じような中身なのかな？
GPL: QuickLZ、LZO クローズ: LZTurboなのか？
LGPLか修正BSDが欲しいと思ってたら、http://www.quicklz.com/ ここで比較してる lzf (LibLZF)ってのが修正BSDだった。
改善しつつ広まって欲しいな。
DeveloperWorks Japan > Linux > FUSEによる独自ファイルシステムの開発
ttp://www.ibm.com/developerworks/jp/linux/library/l-fuse/index.html
ここから辿ってファイルシステム一覧を見てたら、圧縮ファイルシステム一覧があった。
読み書きできて、安定してるやつは他にあるのかな。
ttp://fuse.sourceforge.net/wiki/index.php/FileSystems
・CompressedFileSystems - accessing files in a compressed image (gz, zlib, LiveCDs, etc.)
- compFUSEd
- FuseCompress
- LZOlayer_fs - Transparent compression filesystem
・ArchiveFileSystems - accessing files inside archives (tar, cpio, zip, etc.)
- unpackfs
- avfs - mount archive and compressed files, and access remote files
中身違うと思う。LGPLなLZOはffmpegのlibavutilにあった気ガス。あと7zにもあったような。
(12:33:25)hoge~/$ time tar cf - emacs-21.4 | gzip -1 > emacs-21.4.tar.gz
real 0m35.635s
user 0m32.900s
sys 0m4.500s
(12:34:44)hoge~/$ time tar cf - emacs-21.4 | bzip2 -z -1 > emacs-21.4.tar.bz2
real 2m19.127s
user 2m17.470s
sys 0m3.970s
(12:37:28)hoge~/$ time tar cf - emacs-21.4 | lzma -z -1 > emacs-21.4.tar.lzma
real 2m22.816s
user 2m20.920s
sys 0m5.320s
(12:40:18)hoge~/$ ls -l emacs-21.4.tar.*
-rw-r--r-- 1 *** users 21538172 6月 30 12:37 emacs-21.4.tar.bz2
-rw-r--r-- 1 *** users 28265569 6月 30 12:34 emacs-21.4.tar.gz
-rw-r--r-- 1 *** users 22247714 6月 30 12:40 emacs-21.4.tar.lzma
$ time gzip -9 emacs-21.4a.tar
real 0m23.369s
user 0m18.659s
sys 0m2.363s
$ time bzip2 -9 emacs-21.4a.tar
real 1m9.675s
user 1m3.954s
sys 0m1.605s
$ time lzma -9 emacs-21.4a.tar
real 7m20.250s
user 6m41.498s
sys 0m3.793s
$ ls -lSr emacs-21.4a.tar*
-rw-rw-r-- 1 xxxx xxxx 12644142 Jun 30 15:00 emacs-21.4a.tar.lzma
-rw-rw-r-- 1 xxxx xxxx 16031034 Jun 30 14:59 emacs-21.4a.tar.bz2
-rw-rw-r-- 1 xxxx xxxx 20403499 Jun 30 14:58 emacs-21.4a.tar.gz
$
lzma -9の方が小さいよ。
死ぬほど遅いけど。
-9 使いたいのはやまやまなんだが、手元のマシンがP2-400なんだｗ
lzmaの売りが圧縮率と思うが、時間がかかりすぎるぞ・・・・。
どれだけ圧縮が遅くてもいい。
どれだけ圧縮にメモリを使ってもいい。
展開が激烈には遅くなく（たとえばgzipの数倍以内とか）で、
なおかつ、メモリ使用量がそれなり（たとえば、256MB以内とか）。
この条件でベストのものって何？
何がしたいかというと、
ディストリのインストールDVDを一枚のCDに圧縮したいわけです。
gzipなら4.7GBになるところを、無理やり700MB以内にできないか？
圧縮は、どんなに遅くてもいい。
たとえ、Quad Core で３ヶ月ぐらい掛かっても、
圧縮する価値はあると思う。
DVDなんてダウンロードできないよ！！！。
ヒント: シャノンの理論
シャノンの定理は対象の情報源以外から情報を得られないから
成り立っているように見えるんだよ。
解凍は bzip2 より lzma のほうが速いよ。
圧縮時間も bzip2 並でよければ変わらんし。
・ Average compression ratio of LZMA is about 30% better than that of gzip, and 15% better than that of bzip2.
・ Decompression speed is only little slower than that of gzip, being two to five times faster than bzip2.
・ In fast mode, compresses faster than bzip2 with a comparable compression ratio.
釣りか？
それなら圧縮してる時間をダウンロードにあてれば解決するだろ。
PerformancePage - VFS performance comparison
http://code.google.com/p/fuse-zip/wiki/PerformancePage
他の圧縮もlibzip使って比較してるのか分らないけど、 fuse-zipとavfs-fuseがunpackfsより軽いみたいだ。
それぞれ
CompressFileSystems（圧縮ファイルシステム）は、1ファイルごとにgzなど圧縮ファイルと対応させて管理されて、
ArchveFileSystems（書庫ファイルシステム）zip書庫などをマウントポイントからディレクトリとして使える物みたい
性能測定したらこんな感じになった
■ファイルサイズ（MyISAMのデータファイル）
file 1,127,594,052
(lzo) /tmp/lzo/file 294,154,987 (26.1%)
(gz) /tmp/gz/file 183,510,660 (16.3%)
(bz2) /tmp/bz2/file 未測定
■同一HDD: cp file file2
real 1m5.670s, user 0m0.187s, sys 0m6.112s
動作時のcpu利用率 10% (cp 10%)
■同一HDD(lzo): cp file /mnt/lzo/file
real 0m44.970s, user 0m0.310s, sys 0m4.768s
動作時のcpu利用率 50% (cp 10%, fusecompress 40%)
■同一HDD(gzip): cp file /mnt/gz/file
real 2m8.807s, user 0m0.331s, sys 0m4.469s
動作時のcpu利用率 100% (cp 4%, fusecompress 95%)
■同一HDD(bz2): cp file /mnt/bz2/file
動作時のcpu利用率 100% (cp 2%, fusecompress 98%)
■ヌル出力: cat file > /dev/null
real 0m21.486s, user 0m0.121s, sys 0m1.477s
cat 6%
■ヌル出力(lzo): cat /mnt/lzo/file > /dev/null
real 0m11.340s, user 0m0.211s, sys 0m1.406s
動作時のcpu利用率 60% (cat 10%, fusecompress 50%)
■ヌル出力(gzip): cat /mnt/gz/file > /dev/null
real 0m19.671s, user 0m0.152s, sys 0m1.153s
動作時のcpu利用率 100% (cat 6%, fusecompress 94%)
■ヌル出力(bz2): cat /mnt/bz2/file > /dev/null
動作時のcpu利用率 100% (cat 1%, fusecompress 99%)
real 0m43.200s, user 0m8.009s, sys 0m2.727s
lzop 24%
このDB+WEBの簡潔データ構造の記事みて、いろいろ読んでたら
なんか世の中変わってた。
圧縮データ構造とその最新動向
ttp://www-or.amp.i.kyoto-u.ac.jp/ramp2006/program.html
透過的データ圧縮
ttp://keisan-genkai.lab2.kuis.kyoto-u.ac.jp/reports/2005/zentai_2/
ttp://tcslab.csce.kyushu-u.ac.jp/~sada/lectures/algoeng2006.html
WAN/LANやDB、ファイルシステム、RAM、Cache、内部通信にもこういうものを使う研究もあるみたいだし、
結構わくわくしてきたぞ。
real 0m31.523s
user 0m28.823s
sys 0m1.306s
$ ls -l emacs-21.4a.tar*
-rw-rw-r-- 1 xxxx xxxx 14472688 Jul 7 13:49 emacs-21.4a.tar.rz
$
>>13と同じ環境。
合わせて評価すると速さと圧縮率のバランスがいいかもしれない。
lzmaの4.999α版コンパイルしてみたけど、マルチスレッドにならないし。
7zファイル形式がパイプで使えない原因らしいから、
p7zipがlzmaファイル形式をサポートして、パイプで使えるようになったら良いな〜
これいいな〜と思ったら標準入出力に未対応か・・・
http://zlibc.linux.lu/
lbzip2みたいだぞ
A multi-threaded bzip2/bunzip2 filter
http://phptest11.atw.hu/
Parallel BZIP2 (PBZIP2)
http://compression.ca/pbzip2/
マルチコアCPUを活用したファイル圧縮
http://sourceforge.jp/magazine/08/02/15/0115238
pbzip2 vs bzip2
http://shrine-bell.seesaa.net/article/107520046.html
どっちも並列bzip2の実装。
最近bzip2との互換性が確保されたようなのでpbzip2を試してみた。
カーネルソースを圧縮展開してみたがこれはかなりいい。
LZMAも好きだが圧縮率を求める時代の流れはそろそろ打ち止めだろう。
バランスの面ではpbzip2の方がかなりいい印象。Linuxではpbzip2がすぐに主流になるはず。
pbzip2はよさげだね
>>32
tar.gzは互換性のために生き続ける。
lzmaも場合によってはメリットも大きいはずなのに普及してはきてるけど
あまり表に出てこないのはなんでだろう。
配布に使われないんだから、ユーザもインストールする動機がない。
...の環から、なかなか抜け出せないことが多いだろうな。
ディスクもメモリもネットワークも豪奢な当世、圧縮率に拘るのも少数派だろうし。
あ、lzmaも、ぽちぽち使われているよ。
Linuxカーネル2.6.30とか。
それは書こうかと思ったけどまだ新しすぎるよな・・って思って普及してきてるに止めた。
7zipとしてWindowsでかなり有名なんじゃないかと。
elinksか何かがgzip,deflate以外にbzip2,lzmaが使えたと思うが
ネットでは対応サーバーが皆無だわな
dpkgの依存にlzmaが入っていたりもするし、そろそろlzmaが入ってない環境っていうのは珍しいくらいなのかも。
〜1GhzのCPUでは結構しんどい仕事だから標準をどうするかは難しそう
lzmaは解凍にメモリを多く使うんじゃなかたっけか
それで使いにくいんじゃないかなぁ
そのうち元のファイルが復元できると言い張る奴がいたな
少なくとも file-5.00 は。
こんなのがあった。
p7zipでWindows用の自己解凍アーカイブを作成
ttp://www.commandlinefu.com/commands/view/1402/create-a-self-extracting-archive-for-win32-using-7-zip
cat /path/to/7z.sfx /path/to/archive > archive.exe
へぇー。
でも.exeってウィルス疑惑で忌避される傾向にある気がする。
解凍したzip中のexeは普通に開く不思議
lzoイラネ。
ホントはbzip2系が画像圧縮で有利な技術だから使いたいんだけど、
展開が遅いのがねー。
java中心でもいろいろ議論あって面白いなあ
lzmaになってきたな
復元は圧縮より速いんだっけ
gzipと違って展開プログラムがアセンブラ化されてないからねぇ。
実装としては枯れてるんだからあとは移植するだけなんだが。
巨大なswitch文がある関数の中と外を膨大な回数行き来するような構造になってた。
VS2010で最大限の最適化をかけてasmを吐き出してみたけどほとんど最適化されてない。
これを逐語的にハンドアセンブルするのはかなり骨だろうなー。
古いマシンだとcpu もメモリも辛いけど
圧縮率最高だよ
圧縮はかなり遅いが展開は速い
lzma 9.22 Copyright (C) 2006 Ville Koskinen
Based on LZMA SDK 9.22 Copyright (C) 1999-2011 Igor Pavlov
Usage: lzma [flags and input files in any order]
-c --stdout output to standard output
-d --decompress force decompression
-z --compress force compression
-k --keep keep (don't delete) input files
-f --force force overwrite of output file and compress links
-t --test test compressed file integrity
-S .suf --suffix .suf use suffix .suf on compressed files
-q --quiet suppress error messages
-v --verbose be verbose
-h --help print this message
-L --license display the license information
-V --version display version numbers of LZMA SDK and lzma
-1 .. -2 fast compression
-3 .. -9 good to excellent compression. -7 is the default.
--fast alias for -1
--best alias for -9 (usually *not* what you want)
Memory usage depends a lot on the chosen compression mode -1 .. -9.
See the man page lzma(1) for details.
xzなら-Tでスレッド数を指定できるな。
マジで？ version教えてくださいな。
こちらは、
xz --version
xz (XZ Utils) 5.1.0alpha
liblzma 5.1.0alpha
年も明けたことだし去年のログファイルでも圧縮するかと思って、
tar.xz に圧縮してみたんだけど、tar に引数を渡すのに
ディレクトリ名を渡すのと、ファイル名を渡すので
圧縮後のファイルサイズが 3倍くらい違うんだけどなんで？
$ apt-show-versions tar bzip2 gzip xz-utils
bzip2/squeeze uptodate 1.0.5-6+squeeze1
gzip/squeeze uptodate 1.3.12-9
tar/squeeze uptodate 1.23-3
xz-utils/squeeze uptodate 5.0.0-2
# ログファイル数 212、logディレクトリ容量 703MB
$ find log |wc -l
212
$ du -m log
703 log
みたいな環境で、
tar cJf logs_with_dir.tar.xz log
tar cJf logs_without_dir.tar.xz log/*.log
ってそれぞれ実行。
ls -sh1 *.tar.xz
416K logs_without_dir.tar.xz
1.3M logs_with_dir.tar.xz
$ xz -l logs_*_dir.tar.xz
Strms Blocks Compressed Uncompressed Ratio Check Filename
1 1 414.7 KiB 702.6 MiB 0.001 CRC64 logs_without_dir.tar.xz
1 1 1,246.3 KiB 702.6 MiB 0.002 CRC64 logs_with_dir.tar.xz
-------------------------------------------------------------------------------
2 2 1,660.9 KiB 1,405.3 MiB 0.001 CRC64 2 files
んで、試しに 7z で圧縮するとこれくらい。
$ 7z a logs.7z log
$ ls -sh1 *.7z
428K logs.7z
なんで？
ちなみに tar.gz や tar.bz2 で試すとほとんど差は出なかった。
何も困ってはいないんだけど不思議なので聞いてみた。
> tar cJf logs_with_dir.tar.xz log
> tar cJf logs_without_dir.tar.xz log/*.log
"*.log"以外のファイルやディレクトリがあるんじゃないのか。
前者はlogディレクトリ以下の全てのファイルとディレクトリを対象とするが、
後者はlogディレクトリ以下の"*.log"のみを対象としている。
おー、やっと反応があった。
> "*.log"以外のファイルやディレクトリがあるんじゃないのか。
それが logディレクトリ配下には "*.log"しか置いてないのよ。
$ tar tvJf logs_without_dir.tar.xz | wc -l
210
$ tar tvJf logs_with_dir.tar.xz | wc -l
211
1行違うのはディレクトリ自身の分ね。
それに >>60の "xz -l" の結果を見ても、
Uncompressed のサイズはどっちも 702.6 MiB だし。
tar cf - log/*.log|xz > logs_without_dir_pipe.tar.xz
してみるとどう?
両方↓やってみた。
$ tar cf - log/*.log|xz > logs_without_dir_pipe.tar.xz
$ tar cf - log|xz > logs_with_dir_pipe.tar.xz
$ ls -sh1 logs_with*_dir_pipe.tar.xz
1.3M logs_with_dir_pipe.tar.xz
416K logs_without_dir_pipe.tar.xz
$ xz -l logs_with*_dir_pipe.tar.xz
Strms Blocks Compressed Uncompressed Ratio Check Filename
1 1 1,246.3 KiB 702.6 MiB 0.002 CRC64 logs_with_dir_pipe.tar.xz
1 1 414.7 KiB 702.6 MiB 0.001 CRC64 logs_without_dir_pipe.tar.xz
-------------------------------------------------------------------------------
2 2 1,660.9 KiB 1,405.3 MiB 0.001 CRC64 2 files
やっぱり、当たり前と言えば当たり前だけど、結果は同じ。
あんまり関係ないと思うけど、念の為ログの説明しとくと、
hyperestraierインデックス作成時(maildir対象)のログね。
cronで回した際のログなので使用文字列の重複率非常に高し。
mkdir -p /somewhere/test/dir/log
cd /somewhere/test/dir
time for i in $(seq -w 1 1000)
do
for j in $(seq -w 1 2000)
do echo "test log text line ${j}"
done > log/${i}.log
done
$ du -m log
47 log
$ ls log|wc -l
1000
$ tar cf logs_with_dir.tar log
$ tar cf logs_without_dir.tar log/*.log
$ tar czf logs_with_dir.tar.gz log
$ tar czf logs_without_dir.tar.gz log/*.log
$ tar cjf logs_with_dir.tar.bz2 log
$ tar cjf logs_without_dir.tar.bz2 log/*.log
$ tar cJf logs_with_dir.tar.xz log
$ tar cJf logs_without_dir.tar.xz log/*.log
$ xz -l logs_with*dir.tar.xz
Strms Blocks Compressed Uncompressed Ratio Check Filename
1 1 16.9 KiB 46.4 MiB 0.000 CRC64 logs_with_dir.tar.xz
1 1 13.8 KiB 46.4 MiB 0.000 CRC64 logs_without_dir.tar.xz
-------------------------------------------------------------------------------
2 2 30.7 KiB 92.8 MiB 0.000 CRC64 2 files
$ gzip -l logs_with*dir.tar.gz
compressed uncompressed ratio uncompressed_name
5114261 48650240 89.5% logs_with_dir.tar
5114237 48650240 89.5% logs_without_dir.tar
10228498 97300480 89.5% (totals)
※ bzip2 は "-l" オプションなし
$ ls -al logs_with*tar*
-rw-r--r-- 1 hiro hiro 48650240 2013-01-07 10:27 logs_with_dir.tar
-rw-r--r-- 1 hiro hiro 549025 2013-01-07 10:28 logs_with_dir.tar.bz2
-rw-r--r-- 1 hiro hiro 5114261 2013-01-07 10:27 logs_with_dir.tar.gz
-rw-r--r-- 1 hiro hiro 17336 2013-01-07 10:30 logs_with_dir.tar.xz
-rw-r--r-- 1 hiro hiro 48650240 2013-01-07 10:27 logs_without_dir.tar
-rw-r--r-- 1 hiro hiro 543453 2013-01-07 10:30 logs_without_dir.tar.bz2
-rw-r--r-- 1 hiro hiro 5114237 2013-01-07 10:27 logs_without_dir.tar.gz
-rw-r--r-- 1 hiro hiro 14120 2013-01-07 10:31 logs_without_dir.tar.xz
logs_with_dir.tar.xz の方が 1.2倍くらい大きくなる。
三倍も差があるわけじゃないけど、圧縮率の差が大きいのは
やっぱり tar.xzなんだよなぁ。
*.tar 大きさ同じなのになー、やっぱ不思議。
-rw-r--r-- 1 aaa users 5118621 1月 7 22:29 logs_with_dir.tar.gz
-rw-r--r-- 1 aaa users 13828 1月 7 22:24 logs_with_dir.tar.xz
-rw-r--r-- 1 aaa users 13796 1月 7 22:26 logs_without_dir.tar.xz
xzのやつをxz -dで解いた後xz -9で固めたらこうなった
-rw-r--r-- 1 aaa users 48650240 1月 7 22:24 logs_with_dir.tar
-rw-r--r-- 1 aaa users 48650240 1月 7 22:26 logs_without_dir.tar
-rw-r--r-- 1 aaa users 13692 1月 7 22:24 logs_with_dir.tar.xz
-rw-r--r-- 1 aaa users 13584 1月 7 22:26 logs_without_dir.tar.xz
むむ、ぬぁにぃぃぃ、こっちの環境のせいなのかぁ？
こっちでも、 xz -d して xz -9 してみた。
-rw-r--r-- 1 hiro hiro 48650240 2013-01-07 23:37 logs_with_dir.tar
-rw-r--r-- 1 hiro hiro 48650240 2013-01-07 23:40 logs_without_dir.tar
-rw-r--r-- 1 hiro hiro 16972 2013-01-07 23:37 logs_with_dir.tar.xz
-rw-r--r-- 1 hiro hiro 13668 2013-01-07 23:40 logs_without_dir.tar.xz
やっぱり 1.2倍くらい違う。
えーと、こっちの環境は debian 6.0.6/squeeze で
$ tar --version
tar (GNU tar) 1.23
$ xz --version
xz (XZ Utils) 5.0.0
liblzma 5.0.0
debian パッケージ的には、
$ apt-show-versions tar xz-utils
tar/squeeze uptodate 1.23-3
xz-utils/squeeze uptodate 5.0.0-2
なんだけど、そっちの環境を教えてもらえますか？
tar (GNU tar) 1.26
xz (XZ Utils) 5.0.4
liblzma 5.0.4
だった
さっきやったPCでまた新しくデータを作ってからlogs_with_dir.tar.xzを作って
それを別の二台に送って解凍してからまた固めたらこうなった
一番上が最初のPC
Mem: 1165120 696316 468804 0 10940 328680
Mem: 3915520 129536 3785984 0 9660 85404
Mem: 767544 97744 669800 0 15752 67784
-rw-r--r-- 1 aaa users 13908 1月 8 00:09 logs_with_dir.tar.xz
-rw-r--r-- 1 aaa users 13828 1月 8 00:12 logs_with_dir.tar.xz
-rw-r--r-- 1 aaa users 16948 1月 8 00:16 logs_with_dir.tar.xz
xzとtarは全部同じバージョン
多分13800前後になるんだと思う
なんでか分からないけどディレクトリ付きのほうが
圧縮するときメモリ使うってことじゃないかな
おー、そういう検証はとてもありがたい。
しかし Slackwareが出てくるとは…、年季入ってそうっすね。
こっちのメモリは、↓な感じ。
Mem: 3371996 2639292 732704 0 264628 1622812
まさにwithoutの方頼もうと思ってたら、電源切っちゃいましたか…
メモリの使い方については、xz の man pageの "Memory usage"に
いろいろ書いてありますね。
でも、メモリ搭載量で圧縮率に変動があるとしても、元々のお題の
ディレクトリを含む/含まないによって圧縮率が変わることへの
直接の回答にはなっていないような感じ…
んで、今さらながら より新しいバージョンの xz-utilsの
NEWSを見てみたんだけど、
http://git.tukaani.org/?p=xz.git;a=blob;f=NEWS;hb=HEAD
5.0.3 (2011-05-21)
* liblzma fixes:
- lzma_stream_buffer_encode() no longer creates an empty .xz
Block if encoding an empty buffer. Such an empty Block with
LZMA2 data would trigger a bug in 5.0.1 and older (see the
first bullet point in 5.0.2 notes). When releasing 5.0.2,
I thought that no encoder creates this kind of files but
I was wrong.
なんかこれっぽい感じ。
今日はもう寝るけど、明日にでも sid の
新しいバージョンビルドして確認してみよう。
tar cJf logs_with_dir2.tar.xz log
tar cJf logs_without_dir.tar.xz log/*.log
Mem: 767544 97056 670488 0 15600 67276
-rw-r--r-- 1 aaa users 13908 1月 9 22:33 logs_with_dir.tar.xz
-rw-r--r-- 1 aaa users 16948 1月 9 22:36 logs_with_dir2.tar.xz
-rw-r--r-- 1 aaa users 13812 1月 9 22:34 logs_without_dir.tar.xz
Mem: 1165120 359552 805568 0 7776 196436
-rw-r--r-- 1 aaa users 13908 1月 8 00:47 logs_with_dir.tar.xz
-rw-r--r-- 1 aaa users 13828 1月 9 22:35 logs_with_dir2.tar.xz
-rw-r--r-- 1 aaa users 13812 1月 9 22:36 logs_without_dir.tar.xz
同じPCでも今回はサイズが微妙に違った
てことで xz-utils 5.1.1alpha+20120614 で確認してみた。
なんで 5.0.4じゃないかというと、debian sid に 5.0.4 がなかったから。
試した結果だけど、若干前よりどちらも圧縮率は上がったけど、
圧縮率の差はそのまま。
>>73 の 5.0.3のliblzma fixesは関係なかったみたい。
$ ls -al logs_with*tar*
-rw-r--r-- 1 hiro hiro 16920 2013-01-14 03:54 logs_with_dir.tar.xz
-rw-r--r-- 1 hiro hiro 13836 2013-01-14 03:55 logs_without_dir.tar.xz
$ xz -l logs_with*dir.tar.xz
Strms Blocks Compressed Uncompressed Ratio Check Filename
1 1 16.5 KiB 46.4 MiB 0.000 CRC64 logs_with_dir.tar.xz
1 1 13.5 KiB 46.4 MiB 0.000 CRC64 logs_without_dir.tar.xz
-------------------------------------------------------------------------------
2 2 30.0 KiB 92.8 MiB 0.000 CRC64 2 files
>>67の人が検証してくれたおかげでとりあえず確認できたのは、
どうやらメモリ環境によって圧縮率は変動するらしいってことくらいか。
確かにそれらしいことが xz の man pageの "Memory usage"に
書かれてるけど、ディレクトリありなしによって圧縮率が変動する
ことの理由にはなってないよなぁ。
てことで、なんかすっきりしないけど、解明はあきらめました。
>>67の人は協力してくれてありがとう。
誰かが xz-utilsのソース読み込んで、
この現象をすっきり説明してくれることを願う。
今更だが気になったので実験。
ファイルはGNUのtar-1.26.tar.xzを使用した。
Debian wheezy 7.0
tar 1.26
xz (XZ Utils) 5.1.0alpha
liblzma 5.1.0alpha
Mem: 8104148 2631116 5473032 0 21232 1628468
これをgz,bzip2,xzでそれぞれ -c をつけてリダイレクトして圧縮する。
$ tar -cf tar_with.tar tar-1.26
$ tar -cf tar_without.tar tar-1.26/*
$ du -b * | sort
14899200 tar_with.tar
14899200 tar_without.tar
1763224 tar_without.tar.xz
1788988 tar_with.tar.xz
2348783 tar_without.tar.bz2
2360563 tar_with.tar.bz2
3455923 tar_without.tar.gz
3456187 tar_with.tar.gz
となった。.tarを比較してみる。
$ diff tar_with*.tar
バイナリファイル tar_with.tar とtar_without.tar は異なります
と出力されたのでtarの方に原因があると思われ。
ディレクトリの有無によるファイルサイズの違いについては
xz-utilsよりtarのソースを読んだ方がいいかもしれない。
http://www.byronknoll.com/cmix.html
圧縮率のためならメモリもCPUも使いまくるというポリシーの実装。
ベンチマークを見ると、30MBのファイルを550kBに圧縮できる代わりに、
メモリ20GBと24分という時間をかけている。
すごいけど推奨メモリ32GBはきつい…
プログラム起こす人いたら、仕様書きます。
BWTのWikipedia見て思いついたことなので、私の仕様に不備があったら、
プログラム書かなくっても教えてもらえると助かる
参考までに、
⇒ 『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。
グーグル検索⇒『宮本のゴウリエセレレ』
EVBFQZKA6L
関心がある人だけ見てください。
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
V2TCB
7zは lzma2 や ppmd などから符号を選べる
lzma2を選択したらxzと同じになる
それだけ
■ このスレッドは過去ログ倉庫に格納されています
ニュース
- トライク(三輪自動車)が大型貨物に追突、男性死亡 男児意識不明 ヘルメットなし [蚤の市★]
- 慶應義塾長が国立大の学費増額を提言「年55万→150万に」 文科省の会合で [少考さん★]
- 【MLB】打撃不振…？ 大谷翔平、打ってるのに何故か叩かれる 軽く打って170キロ超え高速ヒットがヤバすぎると話題に 「アンチ涙目w」 [冬月記者★]
- 埼玉の在日クルド人に差別や攻撃 県外からも電話「SNSで見た」 [少考さん★]
- 「実質負担なし」だけに国会論戦が集中する「子育て支援金」 この事態は誰が招いたか 関連法案が衆院通過 [蚤の市★]
- 【過去10年】演技が“イマイチ”だと思う「朝ドラヒロイン」ランキング…3位広瀬すず、2位土屋太鳳を抑えた1位は？ [Ailuropoda melanoleuca★]
- AFC U23アジアカップ カタール2024★8
- AFC U23アジアカップ カタール2024★9
- AFC U23アジアカップ カタール2024★10
- 【酒】日本vsUAE【U23アジアカップ】
- とらせん祝勝会 ★2
- こいせん 全レス転載禁止
- 【朗報】セブン新作「大盛りごはん チキンカツ弁当」たんぱく質32.5g 580円
- 自分と同じアパート同じ間取り部屋に入ると不思議な感じするよな
- ToLOVEるのヤミちゃんってなんで校長に寝取られてんの？
- 運転中にVIPで以外にやることってなんかある？
- アジアって広すぎ&人種文化多様すぎて一括りにされても困るよな [881676371]
- 今何時？？？？？？？？？？？？？？？？？？？