無料の uvf だけで ripgrep とも klogg とも渡り合えます。uvp が効くのは2問目から — 同じ 50GB を3つの土俵で測った

技術解説

3か月かけて、51.25GB の1本のファイルを同じ機械で測り続けました。出てきた答えは、自分でも意外なほど単純でした。

無料版に付いてくる uvf だけで、最速の grep とも、業界標準のログビューアとも渡り合えます。
有料版の uvp が本当に効いてくるのは、同じファイルに2問目を投げたときからです。

3つの土俵に分けて測りました。

その前に——uvf と uvp とは

UwView には画面(GUI)コマンドラインの2つの顔があります。
巨大なファイルを開いて読むのが画面、探すのがコマンドです。

  • uvf無料版に同梱されるコマンド。索引を作らず、ファイルを順番に1回読んで探します
  • uvpUwView Pro(有料版)のコマンド。1回目に .uwvz(元の約1/9・行索引つき)を作り、2回目以降は元ファイルに触りません
  • -open — どちらにも付けられるオプション。uvf ファイル '語' -open と打つと、見つかった行の位置をそのまま画面へ渡して UwView が開きます。画面はもう一度探しません

どちらも Windows / macOS / Linux で単体で動きます。以下の秒数は、すべて同じ Mac・同じファイル・毎回キャッシュを捨てたコールドの値です。

土俵① CLI で1語を探す — uvf 対 ripgrep

まず、いちばん素朴な勝負です。50GB のファイルから「東京」を探す。

50GB・コールド 時間
ripgrep 15.2.0 55.38秒
uvf(無料) 50.82秒

1.09倍。ほぼ互角です。 索引を持たない uvf が、索引を持たない ripgrep とほぼ同じ速さで走る——当たり前といえば当たり前で、どちらも律速はディスクの読み出し速度だからです。このディスクは素で約 950MB/s 出ます。

検索を1種類だけで判断するのは危ないので、7種類(素の検索・-i-E-E 行頭つき・-E -i-v-E -v)の合計も見ておきます。コールドと、その直後の2回目(hot)を足した「2回計」です。

検索7種の合計・2回計 ripgrep uvf(無料)
Mac M4・32GB・3GB 31.35秒 33.29秒 1/1.06(rg の勝ち)
Mac M4・32GB・10GB 157.93秒 145.76秒 1.08倍
Mac M4・32GB・50GB 797.66秒 745.68秒 1.07倍
Windows ノート・16GB・50GB 1,780.77秒 693.84秒 2.57倍
Linux VM・2コア・50GB 1,334.80秒 1,069.35秒 1.25倍

3GB では負けています。 メモリに載る大きさなので、2回目が完全にキャッシュから返る ripgrep が有利です。10GB を超えると載らなくなり、uvf が 7〜8% 前に出ます。

Windows の 2.57倍だけ、桁が違います。 これは uvf が速いのではなく、Windows の ripgrep が遅いからです。既定のメモリマップ読みが 50GB では裏目に出ていて、--no-mmap を付けると 2.89倍速くなります(別記事にまとめました)。uvf はメモリマップを使わないので、この落とし穴を踏みません。

ここまでで言えるのは1つだけです。探すだけなら、無料の uvf で足ります。 有料版を買う理由はまだありません。

土俵② 探して、画面で読むまで — uvf … -open 対 klogg

実務でやりたいのは「探す」ことではなく、「探して、当たった場所を読む」ことです。そこまでの時間を、業界標準の klogg と比べました。

先に、負けていたところから。 v1.6.5 では、50GB のファイルをただ開くだけなら klogg のほうが速いです。

50GB を klogg UwView 無料版 GUI v1.6.5 同 v1.6.6
開く 52.55秒 100.6秒 50.44秒
検索(「東京」94,979件) 55.59秒 88.9秒 測定せず※

【2026-09-19 追記】v1.6.6 で「開く」は逆転しました。 3GB 2.99秒・10GB 10.13秒・50GB 50.44秒で、
klogg(3.65/10.98/52.55秒)より3サイズとも速いです(読み出し 967/966/969 MB/s)。
※ 検索単独は v1.6.6 で測り直していません。v1.6.6 は開くのと検索が同時に走るので、2つを足しても通しにはなりません(実測の通しは 53.7秒)。
以下の本文は v1.6.5 で測ったときの記録として残します。

読み出し速度に直すと、klogg は開くとき 930MB/s・探すとき 879MB/s で媒体の速度を出し切っています。うちの無料版 GUI は v1.6.5 で 486/550MB/s、ちょうど半分でした。これは不具合ではなく以前から公表しているとおりで、直すべき宿題としていました(v1.6.6 で開くほうは 969MB/s になり、この宿題は返しました)。

【v1.6.6 での追記・確定値】この表は v1.6.5 の値です。
v1.6.6 で無料版 GUI の開く経路を作り直し、索引の完成を待たずに検索を始められるようにしました。
50GB で、ファイルを開く操作から行番号つきの結果一覧が画面に出るまで 53.7秒
sudo purge 後のコールド・ストップウォッチ1本)。910 MB/s。コマンドの uvf … -open(v1.6.6)は 50.76秒=963 MB/s で、画面より約3秒速い——開くのも探すのも同時に走らせるようになったので、残る差は画面を描く分と操作の分です。

50GB・「探して、画面で読む」まで 時間 v1.6.6 GUI との比
無料版 GUI v1.6.5(下の表) 189.50秒 3.53倍
klogg 24.11.0 108.14秒 2.01倍
uvf … -openv1.6.6 50.76秒 画面より約3秒速い
無料版 GUI v1.6.6 53.7秒

上で「直すべき宿題」と書いた差は、ここで詰まりました。 画面が、1つ前の版(v1.6.5)のコマンドに追いついたことになります。
3GB・10GB は秒数を出しません——手で測れる精度を超えてしまったためで、3GB では検索語を打ち込んでいる間に開き終わります
以下の表は v1.6.5 の実測ですが、uvf … -open の値だけは 2026-09-21 に v1.6.6 の値へ差し替えました(v1.6.5 は 3.28/10.41/53.69秒)。

それでも、通すと逆転します。

「探して、画面で読む」まで 3GB 10GB 50GB
UwView 無料版 GUI(開く+検索) 5.47秒 36.34秒 189.50秒
klogg(開く+検索) 4.21秒 22.73秒 108.14秒
uvf … -open(v1.6.6) 3.40秒 10.42秒 50.76秒
倍率(対 klogg) 1.24倍 2.18倍 2.13倍

理由は速さではなく、読む回数です。klogg は開くのに1回、探すのにもう1回、ファイルを読みます。 uvf … -open は1回しか読みません。

$ time uvf osm/japan-latest.osm 東京 -open
11.34s user  6.30s system  34% cpu  50.743 total

51.25GB ÷ 50.74秒 = 963MB/s(v1.6.6・上の表の 50.76秒とは別の日の計測で、差は 0.02秒)。CPU は 34% で、残りはディスク待ちです。この50.74秒の中で、探し、索引を作り、画面へ渡し、行番号つきの一覧を出すところまで終わっています。

258.68GB・45億行でも同じでした。 uvf … -open(v1.6.6)が 261.37秒klogg がこのファイルを開き終わるのに 272.10秒(2026-09-21 の全自動計測)かかるので、klogg が開き終わるより先に、こちらは探して画面に出すところまで終わっていることになります。klogg はそこから検索を始めます。ただしこのサイズは CPU 37%で、ディスクの読み出し速度がそのまま天井です——速さの自慢ではなく、読む回数の差です。

ここでも、まだ無料版の話です。

土俵③ 同じファイルに、もう一度 — ここから uvp

境界はファイルサイズではなく、「2問目」にあります。

1問目は、klogg も uvfuvp も、ファイル全体を1回は読まなければいけません。物理の話なので逃げ場がない。
違うのはそのあと何が残るかです。

  • klogg — 索引は残りません。開き直すたびに作り直します
  • uvf(無料) — 索引を作りません。2問目も1問目と同じ時間がかかります
  • uvp(Pro) — 1回目に .uwvz を作ります。2回目以降は元ファイルに触りません
50GB・2回目 開く 検索 合計
klogg 52.55秒(毎回) 55.59秒 108.14秒
uvf … -open(無料・v1.6.6) 50.76秒
uvp.uwvz あり) 0.01〜0.07秒 6.34秒 6.41秒

klogg の 16.9倍、無料版 uvf の 7.9倍。 ここで初めて桁が変わります。

検索7種の合計でも同じ形になります。ripgrep に対して、uvp は 10GB で 3.76倍、50GB で 2.88倍(2回目だけを見れば 3.77倍)。uvf の 1.07倍とは、まったく別の数字です。

.uwvz は元の約 1/9 に縮みます。50GB のファイルなら約 5.7GB。元ファイルを消しても検索でき、-extract で元に戻せます。

正直に書いておくと、3GB では uvp も負けます。 メモリに載っている状態の単発検索は ripgrep が 0.33秒、uvp は 1.01秒。uvp は起動と索引読み込みの固定費を必ず 0.6〜1.0秒払うので、何回やっても逆転しません。この大きさで索引を引く意味は薄い、というだけの話です。

つまり、どう選ぶか

  • 1回だけ探す(画面は要らない)uvf(無料)。ripgrep と互角です。索引もファイルも増えません
  • 探して、画面で読むuvf … -open(無料)探す語が決まっているなら、これがいちばん短い道です。 ファイルを1回読む時間で画面まで届きます(klogg の約2倍)
  • 探す語が決まっていない/とにかく開いて眺めたいUwView 無料版の画面v1.6.6 で「ただ開く」のも klogg より速くなりました——3GB 2.99秒・10GB 10.13秒・50GB 50.44秒(klogg 3.65/10.98/52.55秒)。通しも uvf … -open と同じ 53.7秒です(上の追記参照)。探す語が決まっていなくても、待たされません。 klogg も引き続き優秀で、無料・オープンソースです
  • 同じファイルに何度も戻る/保管もしたいUwView Pro。2回目のオープンが 0.01〜0.07秒、50GB の検索が 6.34秒、保管は元の 1/9

無料版でどこまで行けるかを、はっきり書いておきたかったというのが、この記事を書いた理由です。
uvf は無料で、GitHub Releases から単体で動きます。買う前に、まずそちらで足りるか試してください。

測り方(追試できます)

  • ファイル: OpenStreetMap 日本の XML、51,254,526,392 バイトの1本(10GB・3GB は同じデータの分割片)
  • 語: 東京(固定文字列)。ヒット件数は 3GB 11,274/10GB 11,393/50GB 94,979 で、各ツールとも一致を確認
  • 毎回 syncsudo purge → 10秒待機してからコールドで計測。続けて2回目(hot)
  • Mac M4/メモリ32GB/外付け USB SSD(素読み 約950MB/s)、ripgrep 15.2.0、klogg 24.11.0.1685、UwView v1.6.5(CLI 比較は v1.6.3)
  • GUI は手で測っています(開く=索引が終わって全体を動かせるようになるまで、検索=件数が確定するまで)
  • CLI の出力は全項目で rgsed と突き合わせ、一致 78件・不一致 0件
  • 秒数を環境またぎで比べないでください。 見るのは同じ機械の中の比だけです

条件と全データは実測まとめにあります。関連記事として、ripgrep の no-mmap の話と、klogg と正直に比べ直した話もどうぞ。

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