大容量テキストビューア UwView は、デスクトップ（ネイティブ版・UVF）とブラウザ（WASM版）の両方で動きます。同じコード・同じ機能が一通り動くのですが、当然、実行環境が違えば速度も違います。「ブラウザで動くってことは、遅いんじゃないの？」——気になるところなので、まったく同じファイルを両方で開いて、同じ操作をして実測しました。
計測条件
- ファイル: OpenStreetMap 日本全域を分割した1チャンク
japan-dv-ah（約3.16GB・1億行のXML）:UwViewのテストファイルとしては少なめですが、１億行あるので、一般的には大きなファイルかもしれません。 - 同一マシン・同一フォルダ。ネイティブUVF と ブラウザWASM（
localhostで実行）を順に操作。 - 操作の流れ: 開く → 「東京」を全文検索 → 前後±1行の文脈表示 → 中間・末尾へジャンプ → クローズ。
- 計測は画面操作の実測（秒単位）。検索ヒット数は両者で照合。
結果
| 操作 | 無料版UVF（ネイティブ） | ブラウザ版WASM | 差 |
|---|---|---|---|
| ページモード即表示（開いた瞬間） | 即時 | 即時 | 同等 |
| オープン → 索引完了（行モード） | ≤1秒 | 約35秒 | 約35倍 |
| 全文検索「東京」（両者6,204件で一致） | 1秒未満 | 約15〜20秒 | 約15〜20倍 |
| 前後±1行の文脈表示 | 即時 | 即時 | 同等 |
| 検索ヒット→本文へジャンプ | 即時 | 即時 | 同等 |
| 中間(50%)/末尾(100%)ジャンプ | 各 即時 | 即時（本文表示は即応） | 同等 |
（画像は左＝ネイティブUVF、右＝ブラウザWASM。同じ japan-dv-ah を開いた画面です。）
読み取り
「開いた瞬間に読める」体験は、両者ほぼ同じでした。UwView の核であるページモード即時オープン（ファイル全体を読み込まず、見えている部分から即表示）はブラウザ版でも効いていて、選んだ瞬間から中身が出ます。前後±1の文脈表示や、検索結果から本文へのジャンプといったUI操作もWASMで即応——これらは軽い再描画なので、環境差が出ません。
差が出るのは重い処理＝索引構築と全文検索です。ここはネイティブが圧倒的で、索引で約35倍、検索で約15〜20倍。WASM側は進捗バーが出るレベルの時間がかかります。1億行の索引に約35秒、「東京」検索に15〜20秒。ネイティブはどちらも1秒前後で終わります。
そして重要なのは、検索ヒット数が両者ぴったり6,204件で一致したこと。つまり速度は違っても、結果の正確さは同じです。ブラウザ版だから雑、ということはありません。
なぜこれだけ違うのか
- ネイティブUVFは .NET のネイティブ実行＋メモリマップドファイルで、ディスクとCPUをそのまま使えます。
- ブラウザWASMは WebAssembly 上で動くため CPU が一枚遅く、ファイル読みも非同期の
Blob.slice経由。同じOSキャッシュ状態でも、索引や全文検索のような「全体を舐めるCPU処理」で差が開きます。
逆に言えば、表示や小さな再描画のように”見えている分だけ”の処理は、WASMでも十分速いわけです。
正直な注記
- ネイティブUVFはこのファイルを直前に開いていたためOSキャッシュがwarm（だから索引≤1秒）。ただしWASMの遅さはCPU律速なので、キャッシュを揃えてもこの傾向は変わりません。
- 計測は画面操作ベースの秒単位精度です。
- 名古屋・大阪など他の語も同傾向（各15〜20秒）でした。
使い分け
- ブラウザ版WASMは「インストール不要で、UwViewの機能が一通りその場で動く」のが価値。ちょっと巨大ファイルを覗きたい、共有PCで試したい、という場面に向きます。
- 本気で大容量を扱うなら、無料のネイティブ版UVF。索引も検索も桁違いに速い。
- そしてもっと速く・開き直しも一瞬・アーカイブ保管までとなると、有料の UwView Pro の方向になります。
「ブラウザでも同じ機能がちゃんと動く。ただし本気の速度はネイティブ」——という、想定どおりで気持ちのいい結果でした。UwView は無料なので、大きなログを触る方は、まずはお手元で試してみてください。
関連記事
出典
- amru195704/UwView（GitHub） https://github.com/amru195704/UwView
コメント