search

texjporg / tex-jp-build

Minimum source repository to build Japanese TeX processing tools
23 stars 6 forks source link

（雑感）pTeX 系列のフォーマットファイルの容量 #96

Closed h-kitagawa closed 4 years ago

h-kitagawa commented 5 years ago

このツイートの通り，どうやら次期 LaTeX (2020-02-02?) では expl3 がプリロードされるようです． さて，それに伴って気になるのが，欧文 LaTeX と pLaTeX とのフォーマット容量の違いです．元々

-rw-r--r-- 1 root root 4291213 11月 24 20:50 pdftex/latex.fmt
-rw-r--r-- 1 root root 3765561 11月 15 17:55 xetex/xelatex.fmt
-rw-r--r-- 1 root root 4555898 11月 24 20:50 eptex/platex.fmt

と差がありましたが，expl3 プリロードに伴って

-rw-r--r-- 1 root root  8067042 11月 24 20:50 pdftex/latex-dev.fmt
-rw-r--r-- 1 root root  4507999 11月 23 13:07 xetex/xelatex-dev.fmt
-rw-r--r-- 1 root root 10409871 11月 24 20:50 eptex/platex-dev.fmt

と恐ろしく差が広がってしまっています．

調べてみると，次のようになっているようです．

  1. TFM 情報を格納する font_info という配列の各要素が，TeX82 や pdfTeX では 4 バイトなのが，pTeX 系列では 8 バイトである．
  2. expl3 はそのロードの過程で 65536 個の \fontdimen を持つフォントを 8 個（l3regex 用の intarray）定義する．それによって，font_info は約 520000 要素だけ余計に使われる．
  3. 上記の 1., 2. と合わせて，pTeX 系列では font_info によって 2 MB 以上が余計にフォーマットファイルにダンプされることになる．

欧文 LaTeX と(u)platex.fmt の容量の差が広がること自体は問題ではないと思っていますが，1 つのフォーマットだけで 10 MB 近く，全エンジンの分を合わせると 162 MB（TeX Live の x86_64-linux バイナリ全部とほぼ同じ容量）というのはなんだか気持ちが落ち着かないなあ，という感想です，

h-kitagawa commented 5 years ago

ちなみに，zlib-fmt ブランチで platex-dev.fmt 相当のものを作ると

-rw-r--r-- 1 root root 2322200 11月 24 21:35 eptex-beta/platex-beta.fmt

となります．なお，TeX Live の pTeX にはもともと zlib がリンクされています（SyncTeX 用）．

zr-tex8r commented 5 years ago

一応、フォーマット読込の速度の影響は調べておきたいですね。

h-kitagawa commented 5 years ago

フォーマット読込の速度の影響

手元のノート PC で調べてみました（ログは https://github.com/h-kitagawa/tex-jp-build/blob/zlib-fmt/zlib-fmt/h7k_T495.log）． NVMe SSD なので，差分は展開に CPU を余計に使うことによるものでしょう．

1回あたりの平均実行時間 (ms) tex-jp-build/master tex-jp-build/zlib-fmt
ソース1 129.15 158.12
ソース2 347.75 375.12
h-kitagawa commented 4 years ago

追記です．↑とは別 PC ですが，lzo, lz4hc での圧縮も試してみました．

圧縮方式 なし zlib (-1) lzo (1x_1) lz4hc (-9)
ブランチ trunk zlib-fmt lzo-fmt lz4hc-fmt
バイナリ 656456 586824 668744 787528
フォーマットサイズ 10411227 2322255 3556826 2719458
フォーマット生成時間 [s] 0.725 0.813 0.744 1.759
ソース1 [ms] 139.56 182.71 167.08 145.10
ソース2 [ms] 390.84 441.08 418.67 398.33

lz4hcは展開時の CPU 使用量が少ないですが，ライブラリの容量が大きい＆高圧縮バージョンの lz4hc でもそんなに圧縮率が良くないことがちょっと期待はずれです（普通の lz4 にすると圧縮速度は速いはず）．

h-kitagawa commented 4 years ago

事後になりましたが，lz4 圧縮をtex-live ML に投げました（投稿）．

norbusan commented 4 years ago

@h-kitagawa いろいろの開発をありがとうございましたが、Karlさんと話して、なかなか納得できませんでした。 この更新は、特別の問題を解決するためですか？ そして、cmd line argumentって、だめだと言われました。一つの値を決めて、環境変数を使えた方がいいと言われました。

また何も決まっていませんが、一応これから一杯の開発しない方がいいと思います。Karlさんは納得されてから、まだやっていいかな〜と思っています。

よろしくお願いします。

h-kitagawa commented 4 years ago

@norbusan Thanks for the comment. My motivation for compressing formats is the following:

But I know that modern hardware has tens of gigabytes of storages, so my attempt is not critical one.

Karlさんと話して、なかなか納得できませんでした。

Is the arguable point introducing another library (lz4) only for (un)dumping formats? XeTeX compresses formats since 0.9997 (TL commit 2007-11-21). How was the situation at that time?

cmd line argumentって、だめだと言われました。

I have no hesitation to remove "-conf-level" option. (This is just for testing different compression levels, to find which level is "good" tradeoff).

norbusan commented 4 years ago

Please see Karl's email.

h-kitagawa commented 4 years ago

@norbusan I saw his e-mail, and am making patches (zlib) and tests. Because of other work, my reply will be late tonight (or tomorrow).

norbusan commented 4 years ago

@h-kitagawa no hurry at all!!!! Whenever you have time ... nothing is urgent in the world of TeX!

h-kitagawa commented 4 years ago

r53078 で zlib 圧縮のコードがマージされ，r53094 で reautoconf されました．基本的には 元コメントの zlib-fmt ブランチ と同じようなものです．

諸々の都合でマージ後の確認はまだできていませんが，XeTeX ですでに使われているコードを再利用しただけなのであんまり問題はないはず．

h-kitagawa commented 4 years ago

クローズするのを忘れていました（今週末ぐらいに pTeX in TL2020 のまとめを書こうと思っていますが，そこでもまとめておきます）．