klogg に開くのは負けました。通すと uvf が勝ちます — 50GB で比べ直した

51GB のファイルを開くだけなら、klogg のほうが速いです。52.55秒 対 100.6秒。うちの負けです。

【2026-09-19 追記】この負けは v1.6.6 で返しました。 同じ条件で測り直して 50.44秒（klogg 52.55秒）。
3GB・10GB も含めて3サイズとも klogg より速くなっています。詳しくは記事末尾の「うちの宿題」に追記しました。
以下の表と本文は 2026-09-18 に v1.6.5 で測った記録です。ただし uvf … -open の値は、2026-09-21 に v1.6.6 の値へ差し替えました（v1.6.5 は 3.28／10.41／53.69秒）。

ただし、探すところまで通すと逆転します。 klogg は 108.14秒、uvf … -open は 50.76秒。約2倍。
理由は速さではなく、読む回数です。

その前に——uvf … -open とは

この記事にずっと出てくる uvf … -open を先に説明します。

UwView には画面（GUI）とコマンドライン（uvf）の2つの顔があります。同じ1つの道具で、
巨大なファイルを開いて読むのが画面、探すのがコマンドです。
-open は、その2つをつなぐオプションです。

uvf <ファイル> <探す語> -open

こう打つと、uvf がファイルを1回だけ読んで探し、見つかった行の位置をそのまま画面へ渡して、
UwView の画面が開きます。画面はもう一度探しません。
行番号つきの結果一覧が最初から出ていて、どの行をクリックしても、その場所が本文で読めます。

つまり、grep で当たりを付けてから別のビューアで同じファイルを開き直して探し直す——
あの二度手間をなくすための仕組みです。
この記事に出てくる uvf … -open の秒数は、すべてこのコマンド1本ぶん、
打ってから画面に結果一覧が出るまでの時間です。

• uvf は無料です（UwView 無料版に同梱）。Windows / macOS / Linux で単体で動きます
• -open 自体は v1.6.0 からありますが、1回読みで済むようになったのが v1.6.4、
  索引の待ちまで消えたのが v1.6.5 です。この記事の計測はすべて v1.6.5 です

先に、負けているところから

同じデータの 3GB・10GB・51.25GB（OpenStreetMap 日本を XML に展開した1本のファイルと、その分割片）を、
ただ開くだけ、そして1語を検索するだけの時間です。

開く

検索（「東京」）

ヒット件数は 11,274／11,393／94,979 で、3サイズとも両者で一致しています。
10GB 以上は、開くのも探すのも klogg の勝ちです。

秒数を読み出し速度に直すと、何が起きているかがはっきりします。

このディスクの素読みは約 950 MB/s。klogg はそれを出し切っています。うちの無料版 GUI は、その半分です。
これは不具合ではなく、以前から公表している値（開く 473〜491 MB/s・検索 575〜581 MB/s）どおりで、
仕様がそうなっているということです。ここは直すべき宿題です。（記事の後ろで触れます）

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

実際にやりたいのは「開くこと」ではなく、「探して、読むこと」です。そこまでの時間を測りました。

klogg は、開くのに1回、探すのにもう1回、ファイルを読みます。
UwView の無料版 GUI も2回読み、しかもその読み方が媒体の半分です。だから 3.7倍になります。

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秒 ＝ 963 MB/s。このディスクの素読み（950〜970MB/s）そのものです。（v1.6.6・sudo purge 後。上の表の 50.76秒は別の日の計測で、差は 0.02秒）
CPU は 34%——残りはディスク待ちで、律速は完全に媒体側。
この 50.74秒の中で、探し、索引を作り、画面へ渡し、行番号つきの一覧を出すところまで終わっています。
そのあと画面が出るまでは1秒もかかりません。

10GB では 10.405秒（940 MB/s）、3GB では 3.279秒（882 MB/s）。どのサイズでも、ファイルを1回読む時間そのものです。

参考までに、検索だけを測った uvf コマンドは 871／933／962 MB/s でした。
-open の 882／940／910 はほぼ同じ帯で、50GB でだけ 5% ほど下がります——画面を立ち上げるぶんです。

258GB でも、同じでした

いちばん大きいファイルでも確かめました。OpenStreetMap のアメリカ全土を XML に展開した
258.68GB・45億行の、分割していない1本です。

$ sudo purge
$ time uvf osmUs/us-260726.osm 'New York' -open
56.24s user  40.60s system  36% cpu  4:25.21 total

265.21秒（4分25.2秒）。930 MB/s で、これも媒体の速度です。

最初に測ったときは 250.68秒（984 MB/s）でした。素読みの約950 MB/s を上回っていたので、直前に途中で止めた
実行のキャッシュが数%効いたと見て、sudo purge してから取り直しています。 差は 5.5%。
速いほうではなく、遅いほう（＝キャッシュ無し）を載せます。

ここで、それぞれがファイルを開き終わるまでにかかる時間と並べてみます。

klogg がファイルを開き終わるのとほぼ同じ時間で、こちらは探して画面に出すところまで終わっています
（258秒 対 265.21秒。差は 7秒、2.8%）。klogg はここから検索を始めます。

無料版 GUI で同じことをすると、開く 8分50.1秒 ＋ 検索 7分20.0秒 ＝ 16分10秒。3.66倍です。

（無料版 GUI のこの2つは、同じ日に取り直して同じ値でした——前の計測は 532.6秒／449.4秒で、差は 0.5%／2.1%。読み出し速度は 465／561 MB/s で、50GB の 486／550 とも同じ帯です。）

もちろん、同じファイルに何度も戻るなら Pro です。.uwvz ができたあとの検索は 34.8秒で、
2回目以降のオープンは一瞬になります。1回で済ませたいのか、何度も引くのか——そこが分かれ目です。

なぜ1回で済むのか

v1.6.0 で uvf コマンドを付けたとき、-open は検索語だけを画面へ渡していました。
画面は受け取った語で、自分でもう一度探していました。CLI が全部読んだあとに、画面がまた全部読む。

• v1.6.4 — CLI が見つけた行の位置を画面へ渡すようにしました。画面は探し直しません
• v1.6.5 — さらに、検索のついでに索引の目印も集めて渡すようにしました。
  画面は索引を組み立てるだけで、ファイルを読み直しません。行番号も一緒に渡るので、結果一覧は最初から行番号つきで出ます

どのみち全部読んでいるのだから、数えるものを1つ増やしても、値段はほとんど変わらない。
実際、検索だけを測った uvf の値（3GB 3.32秒／10GB 10.48秒／50GB 50.82秒）と、
上の通し計測はほとんど同じです。受け渡しの上乗せは、ほぼゼロでした。

3GB だけ差が縮みます

倍率をもう一度見てください。3GB では klogg 比 1.24倍で、50GB の 2.13倍よりずっと小さい。

理由は単純で、3GB はメモリ（32GB）に載るからです。klogg も無料版 GUI も2回読みますが、
2回目がキャッシュから返るので、2回読む不利がほとんど消えます（klogg の 3GB 検索 0.56秒、
無料版 GUI の 0.20秒がそれです）。

10GB 以上になると載らないので、2回目も本当にディスクを読みます。 そこで差が開きます。
私たちが以前から「3GB は互角、10GB から差がつく」と書いてきたのは、これと同じことです。

無料版 GUI の 3GB 検索 0.20秒は、手で測れる下限に近い値です。仮に 1.0秒だったとしても
合計 6.27秒＝1.9倍で、結論の向きは変わりません。

うちの宿題

この計測で、自分の弱点がはっきりしました。

無料版 GUI が「開く」ときの読み出しは 486 MB/s。klogg は 930 MB/s。ほぼ2倍の差があります。
CLI の uvf は v1.6.3 で1回読みに作り直して 962 MB/s に届いたので、同じ機械・同じディスクで
それが可能だということは、もう証明されています。 GUI の索引構築を同じ読み方に寄せられれば、
50GB を開くのが 100.6秒から 52秒前後になるはずです。

klogg が媒体の速度を出しているという事実は、こちらにとって「目標値の実測」でもあります。
次の版で詰めます。

【2026-09-19 追記】その次の版で、返しました。
v1.6.6 で索引の完成を待たずに検索を始められるようにしたところ、50GB で
「開いて、探して、行番号つきの結果一覧を画面に出す」までが 53.7秒になりました
（sudo purge 後のコールド・ストップウォッチ1本）。910 MB/s——媒体の素読みそのものです。

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

3.53倍・2.01倍は、v1.6.5 の uvf … -open（53.69秒）が出した倍率とまったく同じ数字です。画面が、1つ前の版のコマンドに追いつきました。
コマンドも v1.6.6 で 50.76秒に縮んでいて、画面との差は約3秒——開くのも探すのも同時に走らせるようになった今、残るのは画面を描く分と操作の分です。
上で「開くのが 52秒前後になるはず」と書きましたが、実際には「開く」だけでなく「探して画面に出す」まで含めて 53.7秒でした。
経緯は別記事にまとめています。
なお 3GB・10GB の通しは手で測れる精度を超えてしまったので秒数を出しません。3GB では、検索語を打ち込んでいる間に開き終わります。

【2026-09-19 追記その2】「開くだけ」も返しました。 この記事で「うちの負けです」と書いた勝負です。

開くだけ（sudo purge 後）	3GB	10GB	50GB
klogg 24.11.0	3.65秒	10.98秒	52.55秒
無料版 GUI v1.6.5（この記事の表）	5.27秒	19.62秒	100.6秒
無料版 GUI v1.6.6	2.99秒	10.13秒	50.44秒
対 klogg	1.22倍	1.08倍	1.04倍

読み出しは 967／966／969 MB/s。486 MB/s の 1.99倍——ほぼ2倍で、3サイズとも同じ値＝媒体の速度そのものです。
上で「52秒前後になるはず」と書いた予想は、50.44秒という形で当たりました。
「開く」も「通し」も、klogg より短くなりました。 ただし klogg が優れたツールであることは変わりません——
無料でオープンソースで、この記事が測った時点ではうちより速かった、という事実も含めて残しておきます。

索引を持っている側の話

ここまでは無料版の話です。有料版の uvp は最初の1回だけ .uwvz（元の約1/9・行索引つき）に変換し、
以後は元ファイルに触りません。同じ 50GB で、

klogg は開き直すたびに索引を作り直します。 ここが「1回だけ見るか、何度も戻るか」の分かれ目です。

選び方

• 1回だけ見る → klogg で足ります。開くのは速いですし、無料でオープンソースです
• 探して、読む → uvf … -open。ファイルを1回読む時間で、画面まで届きます。無料です
• 同じファイルに何度も戻る → UwView Pro。2回目以降のオープンが 0.01〜0.07秒、検索が 6.34秒になります

測り方（追試できます）

• ファイル: OpenStreetMap 日本の XML、51,254,526,392 バイトの1本（10GB・3GB は同じデータの分割片）
• 語: 東京（固定文字列）。ヒット件数は 3GB 11,274／10GB 11,393／50GB 94,979 で、3つとも一致を確認
• 毎回 sudo purge してから10秒待ち、コールドで測定
• Mac M4／メモリ32GB／外付け USB SSD、klogg 24.11.0.1685、UwView 無料版 GUI と uvf v1.6.5
• GUI は手で測っています（開く＝索引が終わって全体を動かせるようになるまで、検索＝件数が確定するまで）

uvf は無料で、Windows / macOS / Linux 版があります。
GitHub Releases から単体で動きます。
索引を作って同じファイルを何度も調べたい場合は UwView Pro です。