UwView Pro — 業界標準 klogg と比較してみたら、設計が30年前の世代だった

比較

大容量テキストビューア UwView の上位版、UwView Pro を発売しました(全OS対応:Windows/macOS/Linux・買い切り $129/月額 $9・製品ページ https://uvp.y42u.net/pro/ )。コアエンジンの実測値がそろっているので、巨大ログビューアの業界標準 klogg との本気の比較結果を紹介します。

先に結論だけ言うと——klogg と現行 UwView(公開版)は、実測するとほぼ同等の性能でした。そして UwView の設計の原型は、30年前(Windows95時代)の旧 UwView です。つまり……業界標準って、思ったより古くないですか? という話と、それを今の時代のハードウェア前提で設計し直したら何が起きたか、という話です。


計測条件 — 実データ48GB・8.9億行

ベンチマークはすべて同一条件・同一ファイルで実施しました。

※ファイル容量の表記について:本記事の「48GB」は 47.73GiB(バイト÷1024³)を丸めた値です。macOS の容量表示(SI・÷1000³)では 51.25GB と表示されます。いずれも同一ファイル(51,254,526,392 バイト)で、説明動画の「51GB」表記もこれに合わせています。

  • 環境: 10コア Mac・RAM 32GB・外付けUSBドライブ(実測物理帯域 0.41GB/s)
  • 比較対象: klogg 24.11.0(メイン検索は常に正規表現エンジン・Match case ON)
  • 検索ヒット数は klogg・UwView・UwView Pro の3者で全パターン厳密一致を確認済み(例: literal “Tokyo” = 10,967件)

第1ラウンド:klogg vs 現行UwView — ほぼ同等だった

項目 klogg 24.11 UwView 公開版
初回オープン(索引構築) 約110秒 128〜186秒
2回目以降のオープン 毎回約110秒(再索引) 毎回128〜186秒(再構築)
検索 literal “Tokyo” 120〜135秒 156.2秒

数字に多少の凸凹はありますが、どちらも「生ファイル48GBを毎回全部読む」設計であることがはっきり分かります。スループットはどちらも0.3GB/s前後——つまりディスクの物理帯域に張り付いているわけで、これはツールの優劣ではなく設計世代の問題です。

念のため書いておくと、klogg のソースコードは一切見ていません。あくまで外側からの実測が同じ物理限界に張り付くことからの推測ですが、「開くたびに索引を作り直し、検索のたびに生ファイルを舐める」という基本構造は、おそらく同じ世代の設計だと思われます。

そして UwView の設計の原型は、Windows95 時代に Vector で公開していた旧 UwView。30年前の設計です。業界標準 klogg の実力が30年前の設計と横並び、というのがこの比較の第一の発見でした。

ただし「同等ですらない」点がひとつ

30年前の旧 UwView から一貫して持っている機能に「開いた瞬間から全域が見える」(プログレッシブ・オープン)があります。現行 UwView も、索引構築中からファイルの中間・末尾へ自由にジャンプできます。

klogg はどうか。実測中に確認したところ、索引構築が終わるまで先頭部分しか見えません(スクロールで中間・末尾へ移動できない)。48GBなら約110秒間、ファイルの末尾は「おあずけ」です。この一点に関しては、30年前の設計と同等……ですらありませんでした。

第2ラウンド:そこで UwView Pro — 設計を「今」に合わせて作り直す

30年前と今で何が変わったか。RAMは数十GBが当たり前になり、CPUは10コア、そして zstd のような「ディスクより速い圧縮」が使えるようになりました。UwView Pro はこの前提でエンジンを設計し直しています。

仕組みの核はサイドカー方式です。詳細は別記事に譲りますが、要点は3つ:

  1. 初回オープン時、索引構築と同時に zstd 圧縮キャッシュを生成する(ディスク読みの合間の遊んでいるCPUで圧縮するため、追加の待ち時間はほぼゼロ)
  2. 2回目以降は保存済み索引を読むだけ(ミリ秒)。検索は 48GB の生ファイルではなく 5.3GB の圧縮キャッシュを読む(読むバイト数が1/9になる)
  3. 圧縮キャッシュは元ファイルの全バイトを無損失で保持し、ブロック単位のチェックサム付き。元ファイルを消して 1/9 サイズで保管しても、そのまま開いて検索できる

総合比較表 — 実測結果

項目 klogg 24.11 UwView 公開版 UwView Pro(発売中) Pro÷klogg
初回オープン 約110秒(完了まで先頭しか見えない 128〜186秒(全域即表示) 140秒(索引+圧縮キャッシュ生成込み・全域即表示) ほぼ同等
2回目以降のオープン 毎回 約110秒 毎回 128〜186秒 0.02〜0.07秒 1,500倍以上
検索 literal “Tokyo” 120〜135秒 156.2秒 14.3秒 約9倍
検索 大小無視 “Tokyo” 約120秒 (未計測) 14.0秒 約8.6倍
検索 regex “Tok[yi]o” 約130秒 (未計測) 29.8秒 約4.4倍
検索 regex “name:en.*Tokyo” 約130秒 (未計測) 29.2秒 約4.4倍
ディスク占有(アーカイブ運用) 48GB(元ファイル必須) 48GB(元ファイル必須) 5.3GB(元ファイル削除可・checksum保護) 1/9

正直な注記

  • 1回目から“見るのは一瞬”。 UwView は開いた瞬間から全テキストを閲覧・スクロール・検索できます(klogg は索引完了まで先頭しか見えません)。索引と圧縮キャッシュは1回目にバックグラウンドで生成(48GBで約140秒。生ファイルを一度読む物理速度=0.41GB/s に依存・その最中も閲覧できます)。索引作成は1回目に行うので、2回目以降は行番号付きで一瞬(0.02〜0.07秒)に開けます。
  • 上記はすべて1つの実環境での計測値です。RAM量・ストレージ速度・ファイル内容で数値は変わります。

開発状況と今後

エンジン部分(並列索引構築・並列検索・サイドカー)は実装済みで、上記の数値はすべて動くコードの実測です。現在は Pro 専用UI(矩形選択のコピー&ペーストなど)まで実装済み。UwView Pro は発売中です(全OS対応:Windows/macOS/Linux・買い切り $129/月額 $9)。 → https://uvp.y42u.net/pro/

現行 UwView(無料)は引き続き GitHub で公開中です。まずは「開いた瞬間に全域が見える」を体験してみてください——30年前からの、UwView の基本です。


まとめ

  • 業界標準 klogg と現行 UwView(30年前の設計がベース)は、実測するとほぼ同等=どちらも「毎回生ファイルを全部読む」世代の設計。
  • 「開いた瞬間から全域が見える」に限れば、klogg は30年前の UwView と同等ですらない(索引完了まで先頭のみ)。
  • UwView Pro は現代のハードウェア(大容量RAM・マルチコア・ディスクより速い圧縮)前提で設計し直した次世代エンジン。
  • UwView / UwView Pro はどんな巨大ファイルでも開いた瞬間から全域を閲覧・検索できます(索引はバックグラウンドで生成・完了後に行番号を表示。UwView Pro は索引と圧縮を保存するので、2回目以降は行番号付きで瞬時)。実測(48GB・8.9億行):2回目以降のオープン1,500倍以上・検索 約9倍・保管サイズ1/9。(索引作成は1回目に裏で行い、2回目からは行番号付きで一瞬に表示できます。)
  • UwView Pro は発売中(全OS対応:Windows/macOS/Linux・買い切り $129/月額 $9)。→ https://uvp.y42u.net/pro/

関連記事

出典

  • amru195704/UwView(GitHub) https://github.com/amru195704/UwView
  • klogg(GitHub) https://github.com/variar/klogg
  • OpenStreetMap data(Geofabrik: japan-latest.osm) https://download.geofabrik.de/asia/japan.html
  • Zstandard(zstd) https://github.com/facebook/zstd

開発者より: アプリ・Kindle本・オープンソースの一覧は GitHub: amru195704 にまとめています。


お願い
本記事の情報は参考目的で掲載しており、正確性・完全性を保証するものではありません。ベンチマーク値は特定環境での実測であり、環境により結果は異なります。誤記・不正確な情報がございましたら、コメント欄よりご指摘いただければ、確認のうえ修正いたします。

コメント

タイトルとURLをコピーしました