- このトピックには28件の返信、1人の参加者があり、最後に
により1週、 3日前に更新されました。
-
投稿
-
TZEditor v0.1.38～0.1.45 を公開しました🚀
エディタ内部のテキスト管理に VS Codeと同じ Piece Table を適用しました。
もともとはVS Code と同じ Piece Tree(Piece Table + 赤黒木)で考えていたのですが、赤黒木の実装が難しすぎて最終的にはPiece Treap(Piece Table + Implicit Treap)となりました。
また、ファイルアクセス方式をメモリマップドファイルに変更し巨大ファイルの読み込み性能を改善しました。
ちなみに、現在の巨大ファイルの対応状況ですが、1000万行(1.25GB)を開くまでの平均処理時間は下記です。
v0.1.37：17.91 秒
v0.1.38：8.23 秒かなりよくなったのですが、まだまだ遅いので引き続き改善していきます。
v0.1.39で気になった点がありましたので、報告いたします。
少し大きめのファイルでのキー操作が遅い
再現手順は
(1) 新規で以下を入力
1行目：🍌
を入力し、これをコピーし、3033606行作ります。
(2) 名前を付けて保存します。
ファイル名：🍌.txt （サイズ：18,201,630 byte）
(3) 175万行あたりで、キー操作
矢印キーや Enterキー連打、BackSpaceキー連打 など。です。
ちなみに、このファイルを開くのに、TZEditorは 11.637秒 かかりました。
（なお、EmEditorでは一瞬、Meryでは 5秒ぐらい。）> igy さん
ご連絡ありがとうございます。
> 少し大きめのファイルでのキー操作が遅い
確認しました。スクロールバーのための
文字幅の計算に時間がかかっているようです。致命的のようですので見直します。> ちなみに、このファイルを開くのに、TZEditorは 11.637秒 かかりました。
> （なお、EmEditorでは一瞬、Meryでは 5秒ぐらい。）こちらは、私の環境では 1 秒未満で開きました。環境の違いとは思うのですが、毎回 11 秒ぐらいかかるでしょうか？
開いたファイルは TZEditor を起動した PC に保存したファイルでしょうか？よろしくお願いいたします。
> 毎回 11 秒ぐらいかかるでしょうか？
TZEditor 起動して、このファイルを開いたら、毎回 11秒ぐらいかかりました。
> 開いたファイルは TZEditor を起動した PC に保存したファイルでしょうか？
はい。PC内の ダウンロードフォルダ に保存しています。
> はい。PC内の ダウンロードフォルダ に保存しています。
なお、ストレージはHDDです。
igy さん
ご連絡ありがとうございます。
可能でしたら、メモリマップドファイル適用前のバージョンで
開くとどれくらいの処理時間がかかるかご確認いただけないでしょうか？読み込み時間を調べてみました。
どちらのバージョンも、設定をデフォルトの状態から、少しずつ設定を変えています。v0.1.37
解凍直後のデフォルト設定
4.638 秒
DirectWrite有効
4.654 秒
ウィンドウの右端で折り返し有効
6.044 秒v0.1.39
解凍直後のデフォルト設定
1.627 秒
DirectWrite有効
1.622 秒
ウィンドウの右端で折り返し有効
11.x 秒
(その後、TZEditor自体が不安定に…タスクバーには表示しているが画面表示せず・・)igy さん
ご確認ありがとうございます。
> v0.1.39
> 解凍直後のデフォルト設定
> 1.627 秒
> DirectWrite有効
> 1.622 秒
> ウィンドウの右端で折り返し有効
> 11.x 秒
> (その後、TZEditor自体が不安定に…タスクバーには表示しているが画面表示せず・・)再現できました。遅い箇所がわかって良かったです。
ただ、現在修正しているのですが、v0.1.37 より速くならないようです😭新バージョンからファイル読み込みは速くなったのですが、テキストを改行も含めた一塊で管理しているため
行頭を知るのに何度も検索が必要になり遅くなっています。なんとか速くならないか試行錯誤してみます。
TZEditor v0.1.40 を公開しました✨
スクロールバーのつまみ表示位置のために一番大きい行長を特定する必要があるのですが、前のバージョンは算出に時間がかかっていたため、巨大ファイルを編集するとカクカクになることがありました。
本バージョンはこちらを改善しカーソル操作がより快適になりました。
ただ、折り返しの計算はまだまだ遅く、暫定で対応してみましたが300万行だとカクカクになります。こちらも改善予定です。
よろしくお願いいたします🙇♂️
TZEditor v0.1.41 を公開しました✨
行の文字列長の算出に時間がかかるためエディタに表示している行のみ計算するようにしました。この変更で巨大ファイルを開く時間が短縮されました。また、マウスホイールによるフォントサイズの変更も快適になりました。
引き続きよろしくお願いいたします🙇♂️
TZEditor v0.1.42 を公開しました✨
大きめのファイルの折り返し計算が遅かったのですが、本バージョンからマルチスレッドを利用して処理するようにしました。ウィンドウサイズ変更時の速度がもう少し速くなればとは思います。。。
参考)
#9392 で作った 300 万行(17.3 MB)を折り返して開いた結果v0.1.41：3.217秒
v0.1.42：1.926秒また、折り返し後のキャレット移動がもっさりでしたが、データ構造を見直し快適に動作するようになりました。
よろしくお願いいたします🙇♂️
v0.1.43でのファイルの読み込み・キー操作 を確認してみました。
ファイルは前回報告した
ファイル名：🍌.txt （サイズ：18,201,630 byte）
です。（ダウンロードフォルダに保存。ストレージはHDD）読み込み時間
5.417秒
（ちなみに、Meryでは 4秒ぐらい）
キー操作（Ctrl+Gで170万行に移動後、↑↓キー操作とEnterキー４回連打し、BackSpaceキー４回連打）
前回より改善されましたが、遅いです。
（ちなみに、Meryでは、普通に操作できました。）> ちなみに、
> 1行目でエンター、BackSpaceと
> 最終行でエンター、BackSpaceで
> もっさり感は変わるでしょうか？1行目と最終行と170万行では、同じぐらいのもっさり感です…となったのですが、
この動作は、私がこれまで使ってきたTZEditorの環境だったので、
前回の読み込み速度のときのように、
解凍直後のデフォルト設定から
・DirectWrite有効
・ウィンドウの右端で折り返し有効
にした環境で試してみたら、読み込み時間
4.743秒
キー操作
もっさり感なく、普通に操作できた
となりました。ということは、私が行った設定変更のいずれかが影響して、
もっさり感が起きることになりそうですね。igyさん
ありがとうございます。
現在、正規表現検索・自動マーカー ON・選択マーカー ON の組み合わせで
もっさり感が出るケースを疑っているのですが、こちらではまだ再現できていません。もし、再現する TZEditor.ini をお持ちでしたら、
本サイトのお問い合わせフォームから 履歴削除後の内容 を貼り付けていただけないでしょうか。■ 履歴削除方法
[オプション] → [履歴] → [履歴の削除]TZEditor.ini の末尾には以下が保存されています：
背景画像のパス
検索文字列
置換文字列
開いたファイルのパス※背景画像を設定している場合は、そのパスも保持されますので、
背景画像の設定も削除していただければと思います。お手数をおかけしますが、ご検討いただけますと幸いです。
> もし、再現する TZEditor.ini をお持ちでしたら、
> 本サイトのお問い合わせフォームから 履歴削除後の内容 を貼り付けていただけないでしょうか。送信いたしました！
原因がわかりました。
スクロールバーに変更行の強調表示をすると[もっさり]になります。
毎回、すべて描画しようとするので行数が多いと、とんでもなく遅くなります。今回ですと300万回描画していました。
こちらの機能は普段使わないので気付きませんでした。あはは。
改善しようと思います。ありがとうございます。
TZEditor v0.1.44 を公開しました🚀
本バージョンでは、巨大ファイル編集時にスクロールバーへ行の状態を描画する際の[もっさり感]を改善しました。従来は全行を走査してスクロールバーに反映していたため、300万行とかになると処理が重くなりカチコチになりました。
今回、スクロールバーの高さをピクセル単位で評価し、そのピクセルが変更行に該当するかどうかで描画する方式に変更し、処理負荷を大幅に軽減しました。ちなみに、今のところスクロールバーはシングルスレッドで描画しています。
よろしくお願いいたします🙇♂️
v0.1.44での300万行ファイルでキー操作、
私の環境でも、もっさり感なく、普通に操作できたのを確認いたしました！これに関連して、気になる点が。
この300万行ファイルを読み込んだときに、
バージョン情報でのメモリ使用量が 1120.6 MB になっており、
・3桁ごとにカンマ表示が好ましいかもしれません。（この例だと、1,120.6 MB）
（タスクマネージャーのプロセスでの表記に合わせて）
・この使用量 は、適正な値ですか？
（他のエディタに比べて使用量が多いですが、メモリ管理上、仕様通りであるなら特に問題はないのですが。）igyさん
ご連絡ありがとうございます。
>私の環境でも、もっさり感なく、普通に操作できたのを確認いたしました！
良かったです。今回の修正で巨大ファイル対応の当初目標の 1000 万行ぐらいでも快適に動作しそうです。
> ・3桁ごとにカンマ表示が好ましいかもしれません。（この例だと、1,120.6 MB）
> （タスクマネージャーのプロセスでの表記に合わせて）こちら、タスクマネージャーと同じメモリ使用量の表示をするようにしましたので、3 桁区切りに修正いたします。
>・この使用量 は、適正な値ですか？
実は他のエディタに比べてメモリ使用量が多くて気にしております。あはは。そのため、すぐ確認できるように、バージョン情報にメモリ使用量を表示するようにしました。
C# で作っていた時は、速度のためなら多少のメモリ使用量は犠牲にしても仕方ない方針だったのですが C++ で作るようになってからはメモリ使用量も極力少なくを目指すようになりました。ただ、保持情報が多すぎなのかもしれません。
他のエディタさんですと特に秀丸エディタさんは DirectWrite を利用してもめちゃくちゃメモリ使用量が少なくどうやってるのか？と思っています。
今後は、起動は最速、起動後もとにかく速く、メモリ使用量は極小で！を目指していきます。
v0.1.45で気になった点がありましたので、報告いたします。
ファイルは
1行目：1
2行目：2
3行目：3
4行目：4のように、行数と同じ数値を入力し、
1000万行のデータを用意しました。（ファイルサイズ：88,888,897バイト）「最小化」すると、「元のサイズに戻す」のに時間がかかり、繰り返すと不安定に。
上記ファイルを開き、「最小化」して、すぐ元のサイズに戻すために、
タスクバーのTZEditorをクリックしても、すぐ元のサイズに戻らず、
時間がたって元のサイズに戻っても、再び「最小化」したら、
タスクバーからTZEditorが消えたり、タスクバーに復活してクリックしても
時間がたっても元のサイズに戻らず。また、「最小化」から元のサイズに戻った直後は、操作ができず、応答なしになる。
検索に時間がかかるケースがある
上記ファイルを開き、検索する文字列：1000000
にて、「次を検索」をクリックすると、時間がかからず、
1000000行目の1000000が見つかるのですが、
さらに「次を検索」をクリックすると、最終行の
10000000行目の1000000
が見つかるまで、8秒ぐらいかかります。igyさん
ご連絡ありがとうございます。
> 「最小化」すると、「元のサイズに戻す」のに時間がかかり、繰り返すと不安定に。
念のためですが、
こちら、ウィンドウの右端で折り返している認識で良いでしょうか？> 検索に時間がかかるケースがある
遅いですね。改善しようと思います。
よろしくお願いいたします。> こちら、ウィンドウの右端で折り返している認識で良いでしょうか？
はい。
郵便番号CSVファイル程度の行数であれば、問題ない感じですが、
300万行・1000万行だと、症状が起きます。
