同じテスト一式を mac・Windows・Linux で流したら、Windows で負けが見つかりました — Wide Field⑬：総合は 2.49／3.42／1.88倍・不一致 0 件、ただし Windows の xz・zst・lz4 は ripgrep の 1/1.5〜1/2.1

この連載の数字は、ほとんど1台の Mac で測ったものです。

UwView は Windows・macOS・Linux 向けに配っています。Mac で「ripgrep と同等以上」と書いたことは、ほかの2つでも本当なのでしょうか。

同じテスト一式を、3台で流しました。

先に結論: 正しさのテスト（145件）は3台とも合格、速さの比較（96項目）でも結果の不一致は 0 件でした。総合は mac 2.49倍・Windows 3.42倍・Linux 1.88倍で、3台とも UwView（uvf／uvp）が速い結果です。大きい1本のファイルでは、Windows で差が最も大きく出ました（50GB の7つの検索で uvf 2.47倍）。一方で、Mac では出なかった負けが Windows で見つかりました。 圧縮ファイルの xz・zst・lz4 で、uvf は ripgrep より 1.5〜2.1倍遅い。原因は、まだ確かめていません

uvf・uvp は私が作っている UwView（v1.7.3.6.9 “Wide Field”・2026年10月4日）の検索コマンドです。uvf は無料版、uvp は有料版 UwView Pro のものです。Windows と Linux は 1.7.3.6.8 で測りました（1.7.3.6.9 との違いは、小さなファイルが大量にある場所の検索だけです）。

3台と、測ったもの

機械がまったく違うので、秒数は OS をまたいで比べません。 並べるのは、それぞれの機械の上での「ripgrep の時間 ÷ UwView の時間」だけです（1 を超えると UwView が速い。1.5倍未満は「同等」）。

Windows の uvf のスレッドが 4本なのは、テスト機の設定ファイルにそう書いてあったからです。既定（論理プロセッサの数まで）ではありません。後で効いてきます。

正しさ: 3台とも合格

Windows の省略 2件は「zip を作る手段がない」（テスト機に Python が無い）ためで、製品の問題ではありません。

速さの比較では、毎回、出力を ripgrep（や sed・sort・uniq の組み合わせ）の出力と突き合わせています。 速くても答えが違えば意味がないので、ここが先です。

大きい1本のファイル: Windows で差が最も大きい

OpenStreetMap の XML（3GB・10GB・50GB）で、7つの検索（素の検索・-i・-E・行頭つき・-E -i・-v・-E -v）を、1回目（キャッシュを捨てた直後）と2回目の合計で比べました。

• Windows では ripgrep の1回目が遅く、uvf の 1.65〜2.53倍かかっていました。uvf は 50GB の2回目でも 2.42倍です。7パターン × 3サイズの21通りすべてで、uvf のほうが速い結果でした。
• Mac では、uvf は ripgrep と同等です（1.00〜1.16）。この連載でずっと書いてきたとおりです。
• uvp は索引（.uwvz）を作る1回目を含めても、3台とも 1.6〜3.7倍速い結果でした。2問目からは索引を読むだけだからです。

Mac の数字だけを見ていると、「uvf は ripgrep と同等」で終わります。 Windows では、同じ uvf が 1.5〜2.5倍速い。どちらも本当で、どちらかだけを書くと、読む人の環境では外れます。

複数のファイル: Windows と Linux では uvf が速い

Linux（論理 2）では、rg -z が gz を展開するために外部の gzip を呼ぶ分が、2コアでは重く効きます。uvf は展開を自分の中で行います。

負け: Windows の圧縮ファイル

圧縮した 1GB・3GB のファイルを rg -z と uvf で探しました（1回目＋2回目の合計）。

1.5倍を超えて負けたのは、Windows の xz（3G）・zst（1G）・lz4（1G・3G）の4か所です。 bz2 と混在も 1/1.2〜1/1.4 で、同等の範囲ながら Windows だけが負け側に寄っています。Mac と Linux では、同じ形式が同等以上でした。

Windows の内訳（3GB・秒。同じ機械の上なので秒を並べます）：

もうひとつ気になる数字があります。1GB の平文の2回目が、Windows の uvf では 0.57秒かかっています（Mac は 0.12秒）。機械が違うので秒を比べることはしませんが、「展開がほとんど要らない場面でも、毎回 0.4〜0.7秒ほどの固定の時間が乗っているのでは」と疑っています。展開の速い zst・lz4 ほど比が悪いのも、固定の時間が効いているなら説明がつきます。

見立て（まだ確かめていません）

Mac と Linux の配布物は NativeAOT（前もって機械語にしたもの）ですが、Windows は「中身を1つにまとめた実行ファイル」で、起動のたびに準備が要ります。NativeAOT は、その OS の上でしかビルドできないので、Mac から Windows 用を作るときにこうなっていました。

確かめ方は決めてあります。W2 は、テスト機の設定（スレッド 4本）を消して、圧縮の比較だけ流し直す。W1 は、Windows 機の上で NativeAOT のビルドを作って比べる。この記事の時点では、どちらもやっていません。

Linux（論理 2）の uvp

uvp は1回目に索引（.uwvz）を作ります。索引は圧縮して書くので、CPU を使います。

2コアの Linux では、展開の速い zst・lz4 と平文で、この1回目が重く、2回の合計で ripgrep の 1/1.2〜1/1.4 でした（gz・bz2・lzma は 1.7〜2.1倍速い）。3回目からは索引を読むだけなので uvp が速くなります。コアの少ない機械で、1回しか探さないなら、uvf か ripgrep で十分です。

正直に書いておくこと

• Windows の圧縮ファイルの負けは、原因を確かめていません。 上の W1〜W3 は見立てです。直ったら、測り直した数字で書きます。
• Windows の uvf は、スレッドが設定で 4本でした。既定の本数で測ると、結果が変わる可能性があります（良くなる見込みですが、測るまで書きません）。
• Windows・Linux は 1.7.3.6.8、mac は 1.7.3.6.9 です。違いは小さなファイルが大量にある場所の検索だけで、この記事の表の項目にはほとんど効きません。
• 3台は CPU・メモリ・ディスクがすべて違います。秒数を OS またぎで比べていません。 比も、その機械の上での比です。「Windows のほうが UwView に有利」ではなく、「Windows のこの機械では ripgrep の1回目が遅かった」と読んでください。
• 50GB はどの機械でもメモリに収まりません。2回目もディスクから読みます。
• 私は自分の製品について書いています。その分は割り引いてお読みください。

持ち帰れる一般論: 1台で「速い」と書かない

（1）負けは、ほかの環境で見つかる。 Mac では同等以上だった圧縮形式が、Windows では 1/2.1 でした。1台で測る限り、この負けは書けませんでした。

（2）環境をまたぐときは、比だけを並べる。 CPU もディスクも違う機械の秒を並べると、何を比べているのか分からなくなります。それぞれの機械の上で「相手 ÷ 自分」を出して、その比を並べました。

（3）速さの前に、答えの一致を3台で確かめる。 速さの比較のすべての項目で、出力を突き合わせています。3台とも不一致 0件でした。

（4）見立てと確認を分けて書く。 「NativeAOT でないから遅い」はもっともらしい話ですが、前回（⑫）は、もっともらしかった mmap の見立てが外れていました。確かめるまでは見立てとして書きます。

使っている道具

UwView は巨大テキスト・巨大ログのビューアです（無料版 UwView／有料版 UwView Pro）。

uvf app.log.zst ERROR                # 圧縮ファイルは展開しながら探す（7 形式・外部コマンド不要）
uvf 'logs/*' ERROR                   # 平文と圧縮を混ぜて、1回で
uvf --tune                           # この機械に合うスレッド数を測る（--apply で設定に保存）

終了コードは grep と同じで、0＝あり・1＝なし・2＝エラーまたは結果が不完全です。

無料版は GitHub Releases から。Mac は brew install --cask amru195704/uwview/uwview、Windows は Scoop（scoop bucket add uwview https://github.com/amru195704/scoop-uwview → scoop install uwview）でも入ります。

リンク

• ⑫ 「秒に出ない」と書いた改行の数え方が、2回目の検索の4割を占めていた: https://uvp.y42u.net/blog/uwview-wf12-newline-hot/
• ⑪ --json と --tune（スレッド数を測って決める）: https://uvp.y42u.net/blog/uwview-wf11-json-and-tune/
• ① 平文と gz の12本を1コマンドで: https://uvp.y42u.net/blog/uwview-wf01-multi-file-one-command/
• ログの圧縮形式の選び方（7形式を実測）: https://uvp.y42u.net/blog/log-compression-format-choice/
• Windows で rg を使っている方へ（--no-mmap）: https://uvp.y42u.net/blog/uvp-rg-no-mmap-50gb/
• 測って分かった「差」の下限（1.5 倍未満を差と呼ばない理由）: https://uvp.y42u.net/blog/uwview-fl09-difference-threshold/
• v1.7.3.6.9 のリリースノート: https://github.com/amru195704/UwView/blob/main/2-doc/release-body-v1.7.3.6.9.md
• 実測の全データ（ベンチマーク一覧）: https://uvp.y42u.net/benchmarks/
• ソースコード（GitHub）: https://github.com/amru195704/UwView

そして、ストレージを専有している巨大ログを圧縮して保管し、さらに高速に検索したいなら UwView Pro をどうぞ。永続索引・圧縮キャッシュ検索・約 1/9 保管で、開き直しも検索も一段速くなります（全 OS 対応・買い切り／月額プランあり）。

開発者より: アプリ・Kindle 本・公開プロジェクトの一覧は GitHub: amru195704 にまとめています。