ホーム特徴大規模テキスト履歴お願いダウンロードライセンス利用料金
2015年12月22日15:20更新
編集、検索、置換などで特殊なユーザー専用の機能をスズカワエディタに追加してほしいという方はご連絡願います。有料ですが低額料金で対応します。
2022年01月27日08:30 追加
スズカワエディタのパクり
2021年05月26日13:00 追加
スズカワエディタの難所
2019年04月03日12:00 更新
スズカワエディタ最新版
2021年04月05日04:00 更新
スズカワエディタ改良版
2019年10月28日15:45 更新
試用版ライセンスキーファイル
2019年04月09日17:30 更新
巨大テキストエディター世界Top3
2015年04月03日11:30 更新
並び替え(ソート、sort)と重複行削除
2014年06月26日11:30 更新
最大ファイルサイズと最大行数
2016年05月06日11:00 更新
複数行テキストの検索・置換
2016年01月12日11:00 更新
カーソル線とテキスト選択
2015年10月05日11:05 更新
テキストエディタ:正規表現
2015年12月04日17:45 更新
改行コードスキップ検索
2013年05月06日13:00 追加
フォルダー参照
2008年12月21日13:00 追加
ファイルサイズ、行数、メモリ、操作性
2007年11月21日12:00 更新
スズカワエディタの紹介
2020年02月28日09:00 更新
ヤフオク!中国人との取引
上図は、スズカワエディタのメインウィンドウです。300GBと40GBの二つのファイルを開いています。このとき使用メモリは40MB以下です。
→詳細
上図は、2,000億行の改行記号だけのファイルに、4千5百万行の5GBファイルを先頭、中間、最後の付近の3箇所に読み込んだテキストです。ウィンドウを3分割しています。ファイルサイズは約390GBです。このとき使用メモリは約30MBです。
→詳細
上図は、四つのスズカワエディタが同時にそれぞれ、ディスク検索、選択部分のコピー、保存、読み込みをしているところです。
→詳細
上図は、1GBファイルを600個読み込んで、ワークファイルフォルダを作成、[ワークファイルフォルダ操作]ダイアログボックスで表示しているところです。そのうち100個を開いています。
→詳細
2023年10月03日13:00 更新
「フェルマーの定理」の解決には330年の年月を要した。ここで敢えて宣言する。スズカワエディタの難所は500年の年月をかけても解決できないだろう。私Suzuki自身は難問中の難問であると信じている。ただし、残念ながら解決したからと言って名誉にも金にも有名にもならないし、何かの賞をもらえるわけでもない。
2019-04-03 12:00
スズカワエディタ最新版:ver05.00.38
2021-04-05 04:00
スズカワエディタ改良版:ver05.01.02
2023-10-03 13;00
2019-10-28 追加
試用版ライセンスキーファイル
2018年06月17日14:00 更新
テスト条件
テキストエディタ | 性能 | 読み込み時間 | 保存時間 | 使用メモリ | 備 考 |
---|---|---|---|---|---|
スズカワエディタ (32bit) | 5TB以上 2兆5000億行以上 | 71分 | 43分 | 約25MB | 備考A |
010Editor (64bit) | 数TB 数千億行 | 22分 | 25分 | 約180MB | 備考B |
PilotEdit (64bit) | 400GB 400億行 | 60分 | 95分 | 約7.5GB | 備考C |
SublimeText (64bit) | 225GB以上 21億行 | 100分 | 30分 | 約28GB | 備考D |
EmEditor (64bit) | 248GB 21億行 | 21分 | 90分 | 約42GB | 備考E |
結果
EmEditorはファイルサイズが約400MBになると折り返し(WordWrap)ができなくなる。約400MB以下のテキストファイルを開くと折り返しメニューは有効であるが、それ以上のファイルサイズのテキストファイルを開くと折り返しメニューが無効表示になり、折り返しを実行できない。折り返しを実行するかしないかの判断基準は不明である。ファイルサイズだけで判断するのか、行数も考慮するのか、あるいは文字数も計算に入れているのか、わからない。
宣伝文句では、ファイルサイズ248GB、行数21億行までのテキストファイルは扱うことができると謳っているのであるが、それにしては400MBは小さすぎる。1GB以上、1000万行以上のテキストファイルを読み込み編集できる世界のテキストエディタの中で、400MB、300万行程度のテキストファイルを折り返しできないのは、EmEditorだけである。
なぜEmEditorは、400MB程度のテキストファイルの折り返しをできなくするのか?
下記の手順で調べてみる。
どうやら、ファイルサイズが数GB程度になると、折り返しを実行したテキストファイルでキーボード入力がチンタラしてスムーズにできないというのが、折り返しをできなくする理由ではないかと思われる。この他に折り返しで行数が大きくなり使用メモリが極端に増加する。保存を実行してみると、途中で止まってしまう症状も見られる。他にも問題があるのかもしれない。いずれにしても、EmEditorなりに諸般の事情を慮って400MB程度で折り返しをできなくしているということだろうと思う。
EmEditorはファイルサイズ248GB、行数21億行まで読み込み編集できるという謳い文句であるが、これだけの巨大テキストファイルをまともに取り扱うに相応しい能力、技量、志を備えていないようである。
内部ファイルに対する複数行テキストの検索・置換に追加。検索条件は同じ。
EmEditorと他のテキストエディタを比較されたい。
表1 - 内部ファイルに対する複数行テキストの検索・置換にかかる時間
テキスト エディタ | ① 1.2GB 920万行 13,457個 | ② 2.4GB 1840万行 26,914個 | ③ 3.6GB 2760万行 40,371個 | ④ 4.8GB 3680万行 53,828個 | ⑤ 6.0GB 4600万行 67,285個 | ⑥ 12.0GB 9200万行 134,570個 | ⑦ 24.0GB 18400万行 269,140個 | 備 考 |
---|---|---|---|---|---|---|---|---|
EmEditor 64bit (ver16.3.1) | 6分02秒 5分30秒 5分05秒 | 22分48秒 21分13秒 19分20秒 | 52分35秒 47分03秒 42分47秒 | 90分08秒 81分38秒 75分24秒 | 141分46秒 129分02秒 117分15秒 | 559分35秒 実行しない 途中終了 | 24時間で中断 約50時間 (約3000分) | 備考A1 備考A |
スズカワ エディタ 32bit | 19秒 14秒 12秒 | 36秒 26秒 25秒 | 55秒 38秒 38秒 | 1分16秒 52秒 48秒 | 1分31秒 1分14秒 1分06秒 | 5分38秒 4分35秒 4分13秒 | 12分53秒 | 備考B1 備考B |
010Editor 64bit | 10秒 | 23秒 | 43秒 | 1分15秒 | 2分05秒 | 7分20秒 | 39分35秒 | 備考C |
PilotEdit 64bit | 45秒 (20秒) | 1分42秒 (49秒) | 2分13秒 (58秒) | 3分00秒 (1分20秒) | 3分41秒 (1分35秒) | 7分51秒 (3分10秒) | 20分46秒 (8分40秒) | 備考D |
SublimeText 64bit | 32秒 | 1分04秒 | 1分35秒 | 2分08秒 | 2分37秒 | 5分10秒 | 14分11秒 | 備考E |
UltraEdit 64bit | 15秒 | 28秒 | 42秒 | 58秒 | 1分12秒 | 途中終了 メモリ不足 | - | 備考F |
巨大テキストエディター 世界Top3に示す通り、巨大テキストを扱うことができるテキストエディタは以下の三つである。
上記の他に、巨大テキスト(ファイルサイズ248GB、行数21億行)を扱うことができると活発に宣伝工作活動を展開しているのが日本のEmEditorである。
EmEditorはファイルサイズ、行数、メモリ、操作性で示す通り、100GB程度のファイルの先頭行で[Enter]キーを押し下げると、その改行作業に1時間もかかるという代物であった。その後2、3年かけて改良した結果、10秒程度まで短縮できたようである。
最近はどうなっているかテストしてみた。
テストに使用したテキストファイルは以下の通り。
( )内の数値は下表の( )付きの数値と対応する。
使用パソコンはこちら。
テスト方法は、上記に示すテキストファイルを読み込んで先頭行で[Enter]キーを押し下げて、改行処理にかかる時間(改行時間)を調べるのである。
EmEditorに限り3つの行数(20億行①、10億行②、5億行③④)について、他の三つのテキストエディタは行数20億行①のケースだけをテストした。
結果は以下のとおり。
下表で( )が付いていない数値は1行当たりの文字数:約100個のテキストファイル、
EmEditorの( )付きの数値は1行当たりの文字数:約10個のテキストファイル、
EmEditorの④は1行当たりの文字数:約400個のテキストファイル、
それぞれに対して改行テストを実行したものである。
表1 - [Enter]キーによる改行処理にかかる時間
テキストエディタ | ファイルサイズ 行数 | 読み込み時間 | 使用メモリ | 改行時間 | 備考 |
---|---|---|---|---|---|
EmEditor 64bit | ① 約190GB (約19GB) 20億行 | 25分15秒 (9分52秒) | 約12GB (約12GB) | 16分32秒 (12分50秒) 8分30秒 (8分2秒) | 備考A |
② 約95GB (約11GB) 10億行 | 11分46秒 (4分18秒) | 約12GB (約12GB) | 7分10秒 (4分55秒) 3分34秒 (2分30秒) | ||
③ 約48GB (約5.8GB) 5億行 | 5分10秒 (1分12秒) | 約11GB (約11GB) | 1秒 (1秒) 1秒 (1秒) | ||
④ 約220GB 5億行 | 25分42秒 | 約9GB | 1秒 | ||
スズカワエディタ 64bit | ① 約190GB 20億行 | 55分44秒 | 約20MB | 0秒 | 備考B |
010Editor 64bit | ① 約190GB 20億行 | 24分30秒 | 約200MB | 0秒 | 備考C |
PilotEdit 64bit | ① 約190GB 20億行 | 107分42秒 | 約8.3GB | 0秒 | 備考D |
改行時間の上段はテキストファイルの先頭行で、下段はテキストファイルの中間行付近でEnterキーを押し下げた場合の時間を示す。いうまでもないことであるが、これは0秒でなければならない数値である。改行時間は一瞬(0秒)であるのが当たり前の話である。ところが1行改行するのに10分以上もかかる。
テスト結果から結論すると、EmEditorは行数10億行以上のテキストファイルを自由自在に扱うことはできないだろう。大容量メモリ、高性能CPUを装着したパソコンを使用しても20億行ファイルをさくさく編集したり、スムーズにスクロールすることは難しいのではないか。
改行が自由自在ではないのだからテキストを編集するツールであるテキストエディタとしては失格である。では、テキストを見るだけのツールであるテキストビューワーとしてはどうか。読み込んだテキストファイルで一行目から最後の行まで見ようと鉛直スクロールバーでスクロールタブを上下方向にドラッグしてみると、これがスクロールできないのである。20億行というのは大変な行数である。[PageUp]キー、[PageDown]キーで全行をスクロールするのは膨大な時間がかかる。全体を概観するのはやはり鉛直スクロールバーを使用するのがよいだろう。しかし、そのスクロールが思うに任せないのである。つまりテキストビューワーとしても失格ということである。先頭や最後、任意行にジャンプするのはもちろんできる。
読み込みは確かに速い。しかし、編集も駄目、見るのも駄目。そうすると、EmEditorは読み込んだ後、何するの?
5億行まで行数を減らすと、ファイルサイズに関係なく(③と④)、一瞬、間をおいて改行する。表ではこれを1秒とした。鉛直スクロールバーのドラッグによるスクロールもスムーズにできるようになる。高性能パソコンを使用すれば、10億行ぐらいまでは大丈夫かもしれない。
他の三つ、スズカワエディタ、010Editor、PilotEditは各自の最大ファイルサイズ、最大行数のテキストファイルで{Enter]キーによる改行、鉛直スクロールバーのドラッグによるスクロールは一切問題なくできるのである。
複数行テキストの置換でもそうであったが、EmEditorは他のテキストエディタに比較すると技量不足の感を免れないのである。
読み込み時間はEmEditorや010Editorに比較すると2倍以上かかる。これは外部ファイルを読み込みながら、ワークファイル(ワンダーファイル)を作成し、保存する作業に時間がかかるためである。スズカワエディタは一旦外部ファイルを読み込むと、編集しても外部ファイルとして保存しなくても、一瞬で閉じることができる。次回から、「ワンダーファイラー]で一瞬のうちに開き編集作業を再開できる。前回以前の編集に対してもUndo、Redoが有効に機能する。一旦読み込んだファイルを瞬間的に開いたり閉じたりする機能、これを仮に「瞬間開閉機能」ということにする。瞬間開閉機能はもちろんスズカワエディタだけのものである。また、この機能がなければ超巨大テキストファイルを扱うことはできないのである。
スズカワエディタはファイルサイズ5TB以上、行数2兆5千億行以上を編集できる。当然のことながら、[Enter]キーによる改行も問題ない。鉛直スクロールバーのドラッグによるスクロールは010EditorやPilotEditに比較するとぎこちないが問題はない。
この中で、読み込みが一番速い。読み込み速度はEmEditorと同じ位である。しかし、鉛直スクロールバーを上下にドラッグすると、ページが滑らかにスクロールする。この点はEmEditorとは天地の違いである。
キーボードによるテキスト編集も問題ない。[Enter]キーによる改行も問題ない。
この中で、読み込み速度は一番遅い。しかし、キーボードによるテキスト編集はさくさくできる。[Enter]キーによる改行も問題ない。鉛直スクロールバーのドラッグによるスクロールも滑らかにできる。
複数行テキストの検索と置換ができるテキストエディタは世界広しといえども10個に満たない。この中で文字数が100万個以上の検索文字列を置換できるのはスズカワエディタとSublimeTextの二つだけである。世界で二つしかないということである。
二つのテキストエディタを大きい検索文字列の検索・置換で比較してみる。
テストに使用した検索ファイル、検索文字列は日本語(Unicode = UTF-16LE)、置換文字列はアルファベット9文字である。検索文字列のバイト数は1文字あたり2バイト。使用パソコンはこちら。
結果は以下の通りである。
表1 - 文字数が大きい検索文字列の検索・置換にかかる時間
テキストエディタ | ① ファイルサイズ:6.0GB ファイル行数:4600万行 検索文字列文字数:100万個 検索・置換数:60個 | ② ファイルサイズ:18GB ファイル行数:13800万行 検索文字列文字数:1000万個 検索・置換数:180個 | ③ ファイルサイズ:120GB ファイル行数:92000万行 検索文字列文字数:5億個 検索・置換数:100個 | 備 考 |
---|---|---|---|---|
スズカワエディタ 64bit | 24秒 内部ファイル | 6分32秒 外部ファイル | 42分22秒 外部ファイル | 備考A |
SublimeText 64bit | 123秒 内部ファイル | 12分30秒 内部ファイル | - | 備考B |
表中の②は同じ検索条件ではないが、スズカワエディタの方がSublime Textより検索・置換の処理作業が迅速で実行も速いと結論づけても差し支えないだろう。
複数行テキストの検索と置換ができるテキストエディタで検索できる文字列の大きさ(文字数)を調べてみた。
テストに使用した検索ファイル(約5GB)、検索文字列、置換文字列は日本語(Unicode = UTF-16LE)である。バイト数に換算する場合は1文字あたり2バイトで計算するとよい。下記の説明では、「外部ファイル」はHDD、SSDに収納されているファイル、「内部ファイル」は外部ファイルをそれぞれのテキストエディタに読み込んで独自に処理したファイルのことである。
使用パソコンはこちら。
結果は以下の通り。結果に異論がある方々、もっと詳細に知りたい方々は自分自身で確認してください。
外部ファイルに対する複数行テキストの検索・置換、複数行テキストの検索と置換で示す通り、検索・置換できる数量でもスズカワエディタが世界一であるが、検索・置換できる文字列の大きさでもスズカワエディタがダントツの世界一というわけである。
検索できる文字列が大きいほうが小さいよりいいことであるのは誰でも異論はなかろうと思う。しかし残念ながら、私(鈴木)は大きい検索文字列を生かす分野、使用方法を知らないのである。もし「大きい検索文字列」が活躍できる場面があるならばご教示願いたい。
現在5億個であるが、実はこんなものではない。正規表現は使用できないが、100億個でも検索・置換できるのである。しかも使用メモリは100MB以下になるだろう。ただし、その実現には時間と労力と気力が必要である。
複数行テキストの検索・置換ができるテキストエディタは世界でも限られているようだ。そのうち、ファイルサイズが5GB以上、行数が5000万以上のテキストファイルを処理できるテキストエディタをここで取り上げる。もちろん、世界のテキストエディタをすべて調べたわけではない。もし、ここで取り上げていないテキストエディタがあれば、ご連絡願いたい。
秀丸エディタ、Mifesについては前回のテストでも明らかであるが、ここで取り上げるだけの性能を備えていない。
以下の説明の中で出てくる「前回のテスト」とは、内部ファイルに対する「複数行テキストの検索と置換」を指している。
外部ファイルに対する複数行テキストの検索・置換も参考にされたい。
外部ファイルを読み込んだテキスト(内部ファイル)に対する複数行テキストの検索・置換にかかる時間を調べた結果を下表に掲載する。表中の数値は前回のものをそのまま掲載している場合と今回新しく追加した場合がある。
今回のテストも前回のテストで使用した条件と同じである。
下表に示す通り、EmEditorが異常に遅い。スズカワエディタと比較すると約100倍の時間がかかっている。EmEditor以外のテキストエディタたちに大きい差はない。それぞれ、恥ずかしくない結果を出している。EmEditorだけが極端に低速である。EmEditorの技量と姿勢には深刻な問題があると言わざるを得ない。
表1 - 内部ファイルに対する複数行テキストの検索・置換にかかる時間
テキスト エディタ | ① 1.2GB 920万行 13,457個 | ② 2.4GB 1840万行 26,914個 | ③ 3.6GB 2760万行 40,371個 | ④ 4.8GB 3680万行 53,828個 | ⑤ 6.0GB 4600万行 67,285個 | ⑥ 12.0GB 9200万行 134,570個 | 備 考 |
---|---|---|---|---|---|---|---|
EmEditor 64bit | 5分30秒 5分05秒 | 21分13秒 19分20秒 | 47分03秒 42分47秒 | 81分38秒 75分24秒 | 129分02秒 117分15秒 | 実行しない | 備考A |
スズカワ エディタ 32bit | 14秒 12秒 | 26秒 25秒 | 38秒 38秒 | 52秒 48秒 | 1分14秒 1分06秒 | 4分35秒 4分13秒 | 備考B |
010Editor 64bit | 10秒 | 23秒 | 43秒 | 1分15秒 | 2分05秒 | 7分20秒 | 備考C |
PilotEdit 64bit | 45秒 (20秒) | 1分42秒 (49秒) | 2分13秒 (58秒) | 3分00秒 (1分20秒) | 3分41秒 (1分35秒) | 7分51秒 (3分10秒) | 備考D |
SublimeText 64bit | 32秒 | 1分04秒 | 1分35秒 | 2分08秒 | 2分37秒 | 5分10秒 | 備考E |
UltraEdit 64bit | 15秒 | 28秒 | 42秒 | 58秒 | 1分12秒 | 途中終了 メモリ不足 | 備考F |
ファイルサイズ1GB以上、行数1千万行以上のテキストファイルを扱えるテキストエディタで、複数行テキストの検索・置換機能を備えているのは次の通りである。順序は扱うことができるファイルサイズ、行数が大きい順に並べている。
外部ファイルに対する複数行テキストの検索・置換、複数行テキストの検索と置換 の二つのテストから判断して、日本勢のEmEditor、秀丸エディタ、Mifesは複数行テキストの検索・置換機能では世界に伍していくのは、残念ながら、難しいだろう。二つのテスト結果を見れば、説明は不要であろう。
スズカワエディタ改良版は、複数行テキストの検索・置換機能の追加を主軸に置いています。改良の進捗状況は以下のとおりです。
複数行テキストの検索・置換機能は当初、上記の1と2だけしか念頭になかったのですが、改良中にそれだけでは不十分という考えに変化しました。2015年2月頃から改良を始めて、1年半近く時間がかかっています。しかし、複数行テキストの検索・置換機能は便利なものであり、未来を開く可能性があると感じるようになりました。この機能を備えているテキストエディタは世界でも数えるほどしかないようです。それも一応備えているが、いずれも性能は十分ではないという状況です。複数行テキストの検索・置換機能の充実は長い時間をかけるだけの価値があると確信しています。
改良中にいくつか課題が見えてきましたが、これについてはまたの機会にして改良は一旦終了するつもりです。現在は周辺機能を整えているところです。これがなかなか時間がかかるのです。
スズカワエディタ改良版は、複数行テキストの検索・置換機能の追加を主軸に置いています。「複数行テキストの検索と置換」ではテキストエディタのテキストウィンドウに読み込んだテキスト上で複数行テキストの検索・置換をいろいろ試しましたが、ここでは外部ファイル(HDD、SSDに収納されているテキストファイル)に対する複数行テキストの検索・置換を試してみます。
テストするパソコン環境、テキストエディタ、テキストファイル、検索文字列、置換文字列は「複数行テキストの検索と置換」と同じです。
結果は以下の通りです。
各テキストエディタの上下2段の欄は上段が検索・置換、下段が検索のみの場合である。
表中の時間は検索・置換と検索のみにかかる時間を示す。バックアップができる場合はバックアップ時間も含まれる。
検索リストは検索結果、置換リストは置換結果を示すリスト。
表1-1
テキスト エディタ | 性 能 | 置換 バック アップ | 置換 リスト | ① 1.2GB 920万行 13,457個 | ② 2.4GB 1840万行 26,914個 | ③ 6.0GB 4600万行 67,285個 | ④ 12GB 9200万行 134,570個 | ⑤ 120GB 9億2000万行 1,345,700個 | ⑥ 1200GB 92億行 13,457,000個 | 備 考 |
---|---|---|---|---|---|---|---|---|---|---|
検索 リスト | ||||||||||
スズカワ エディタ 32bit | 5TB以上 2兆5000 億行以上 | 可 | 有 | 20秒 | 35秒 | 1分28秒 | 4分45秒 | 49分43秒 | 505分24秒 | 備考A |
有 | 14秒 | 18秒 | 47秒 | 2分04秒 | 21分44秒 | 222分18秒 | ||||
010 Editor 64bit | 数TB 数千億行 | 不可 ? | 有 | 12秒 | 33秒 | 2分53秒 | 10分20秒 | 127分05秒 | 省略 | 備考B |
有 | 8秒 | 15秒 | 34秒 | 1分11秒 | 36分35秒 | TimeOver | ||||
Pilot Edit 64bit | 400GB 150億行 | 不可 ? | 無 | 50秒 | 100秒 | 5分20秒 | 10分48秒 | 112分05秒 | - | 備考C |
有 | 41秒 | 78秒 | 3分28秒 | 7分28秒 | 195分00秒 | - | Em Editor 64bit | 248GB 21億行 | 可 | 無 | 910秒 | 実行しない (2300秒) | - | - | - | - | 備考D |
有 | 18秒 | 37秒 | 1分24秒 | 2分50秒 | 37分30秒 | - | ||||
秀丸 エディタ 64bit | 数十GB 1億行 | 可 | 有 | 499秒 | 1831秒 | - | - | - | - | 備考E |
有 | 18秒 | 35秒 | 1分17秒 | 2分35秒 | 25分52秒 | - | ||||
MIFES 32bit | 2GB 数億行 | 可 | 有 | 59秒 | - | - | - | - | - | 備考F |
有 | 14秒 | - | - | - | - | - |
表1-2
テキスト エディタ | 備 考 |
---|---|
スズカワ エディタ 32bit | 検索・置換はファイルサイズ、検索量が大きくなるとスズカワエディタが最速。⑤では検索のみの場合でも010Editorを抜いてスズカワエディタが最速。 ⑥を完遂できるのはスズカワエディタのみ。私(鈴木)のパソコン環境と時間が許せばもっと大きいファイルサイズ、もっと大量の検索量で試したいのであるが、今のところそれができない。本テストは1200GBで終了するが、スズカワエディタはファイルサイズが10TBでも100TBでも検索文字列が10億個でも100億個でも安定して検索、置換、読み込み、表示ができる。 検索リストから置換前の検索文字列と置換後の置換文字列をそれぞれのテキストウィンドウで表示できる。これは便利な機能であるが、置換前のファイルと置換後のファイルをそれぞれ読み込む必要がある。⑥の例では読み込み時間はそれぞれ約260分ずつかかっている。これは現在スズカワエディタのみができる世界唯一の機能であるが、いずれ他のテキストエディタも模倣することになるだろう。 |
010 Editor 64bit | ここで取り上げたテキストエディタの中では検索は最速。検索・置換はファイルサイズ、検索量が小さいうちは速いが、大きくなると処理速度は落ちてくる。③~⑤ではスズカワエディタの方が速い。 ⑥の検索はTimeOver。14時間以上経過しても表示されるプログレスバーに進捗が見られない。メモリは13GB。CPU使用率は0~2%。「応答なし」状態を呈することはない。検索リストが表示されているが、もちろんすべてではない。14時間待ったが、作業が進捗している様子がみられない。強制的に終了。 ⑥の検索・置換は省略。⑤の結果(検索・置換/検索=127分/37分≒3.4倍)から推測して、TimeOverで完遂できない⑥の検索と同様に完遂できないものと考えられる。したがって、⑥の検索・置換テストを省いても、本テストが公平性と信頼性を欠くことにはならないと判断した。 バックアップはもしかしたら、私(鈴木)が操作方法を知らないだけで、できるのかもしれない。 |
Pilot Edit 64bit | 検索・置換速度は格別速いというわけでもない。検索のみの場合はここで取り上げたテキストエディタの中で一番遅い。 ⑤では検索・置換より検索のみの方が時間がかかっている。これはリストの作成時間の有無が原因と考えられる。検索・置換では置換リストは作成されないが、検索のみの方は検索リストが作成される。 検索・置換処理中、進捗具合を示す表示がないので、ファイルサイズが大きく時間がかかる場合は処理時間の計測に苦労する。⑤では正確な処理時間を知るために結果として検索・置換と検索のみのテストをそれぞれ2回ずつ実行しなければならなかった。PilotEditのテストが一番手間取った。 バックアップはもしかしたら、私(鈴木)が操作方法を知らないだけで、できるのかもしれない。 |
Em Editor 64bit | 検索・置換は2GBを超えるテキストファイルに対しては実行できない。248GB、21億行までのテキストファイルを扱うことができるという謳い文句であるが、たかが2GB程度のファイルを検索・置換できないとは驚き呆れるばかりである。 ②の( )内の時間(38分20秒)は約2000MBに削って試した場合を示す。ここで取り上げたテキストエディタの中では最も遅い。「複数行テキストの検索と置換」でも異常な低速ぶりを示したのであるが、こうなると、EmEditor開発者のプログラム技量に問題があると言わざるを得ないだろう。 置換中ダイアログが表示されるが、進捗状況を示す変化が全くなく表示の意味がない。 ただし、検索だけの場合は2GBを超えるテキストファイルに対しても実行できるし、他のテキストエディタに比較して特別に遅いということはない。 |
秀丸 エディタ 64bit | 秀丸エディタは何をやっても特別に高速でもなく特別に低速でもないが、検索・置換はかなり遅い。ただし、検索だけの場合はかなり速い。 ③の検索・置換についてはテストを省いた。②が30分もかかっているので、できるとしてもその2倍(1時間)以上はかかるだろう。 ⑤の120GBファイルは一応最後まで検索し検索リストも最後まで作成する。処理速度はスズカワエディタに次いで2番目に速い。さて、次の操作段階として検索リストから検索文字列を表示するために検索ファイルを読み込む必要があるが、残念ながら1億行の行数制限で最後まで検索ファイルを開くことができない。 |
MIFES 32bit | 特別高速ということもなく、特別低速というわけでもない。 |