以下のような問題が発生しているようです。(しかし自分の環境では再現できず)
https://github.com/sakura-editor/sakura/pull/125#issuecomment-399997904
@ds14050
ところで「hwnd」や「sakura」で GREP したときは起こらなかったのですが、「a」を GREP した際に「GREP実行中」ダイアログと「処理の実行中」ダイアログが交互に前に出て操作ができなくなりました。ver.2.3.2.0 では起きなかったのですが master では起こります。つまりこの PR が原因ではありませんが、わかりましたら教えてください。
https://github.com/sakura-editor/sakura/pull/125#issuecomment-400115005
@beru
77 をマージする前の 8f9531bb13c399e5b39601f044a6cb50e3a7f50a ではその現象が起きないので自分が加えた変更が原因ですね。またこのPRの変更で更に発生しやすくなっています。
調べてみたところ以下のようなロジックで発生するようです。
ファイル
sakura_core/CSearchAgent.cpp内のCSearchAgent::ReplaceData()において進捗ダイアログの表示を行っているのですが、表示する条件として3000行以上の行変更としています。GREP処理の変更で
CGrepAgent::AddTail()の呼び出しに間を設けるようにしたので、それで一度に加わる行が多いケースが起きやすくなったのが原因ですね。呼び出しの流れは以下の通りです。CSearchAgent::ReplaceData() CLayoutMgr::ReplaceData_CLayoutMgr() CEditView::InsertData_CEditView() CViewCommander::Command_ADDTAIL() CGrepAgent::AddTail() CGrepAgent::DoGrepFile() CGrepAgent::DoGrepTree()進捗ダイアログを表示するかの条件が3000行以上という判定をしていますが、テキストデータのサイズとかPCのスペックによって処理負荷は変わると思うのでこの判定方法はどうだろうかとは思うのですが、とりあえずその妥当性はひとまず考えないでおきます。
GREP実行中にリアルタイム表示ONでテキストを追加するからといって進捗ダイアログを表示する必要があるかというと無い気がします。という事で何かしら改造を加えて進捗ダイアログ表示をするかどうかを制御できるようにするのが良いと思います。
リリースを考えるとGREP実行中のリアルタイム表示の画面更新周りは元に戻すのが安全策ですが。。
https://github.com/sakura-editor/sakura/pull/125#issuecomment-401528203
@beru
「リアルタイム表示」のチェック状態は ONで発生します。
条件:a ファイル:*.txt *.h *.cpp *.c *.cc *.hpp フォルダ:サクラエディタのgitリポジトリのフォルダ(.git自体ではなくそのフォルダがある場所です) サブフォルダからも検索する:ON
(しかし自分の環境では再現できず)
追加のGrep条件を記載します。
後気になる点としてはHDDだとストレージの転送速度が遅くて再現しにくいかもしれないです。ディスクキャッシュに入ってしまえば速いので何回か grep を繰り返すのも良いと思います。
処理速度が速いほど発生しやすかったりしますか?デバッグビルドとリリースビルドだったら後者のほうが発生しやすいとかもあったりしますかね?
処理速度が速いほど発生しやすかったりしますか?デバッグビルドとリリースビルドだったら後者のほうが発生しやすいとかもあったりしますかね?
処理速度が速いほど発生しやすいです。
一定時間内に見つけた検索結果をエディタに追加出力しますがその際の行数が一定以上だと出るのでそういう条件が出やすいファイルを作って検索すると再現しやすいと思います。
例えば上記のファイルを展開後に開いて、現在編集中のファイルから検索、をするとどうでしょうか? ファイル毎最初のみ検索 はチェックは外す必要があります。
もしそれでも出なかったらPCスペックの問題なのか、、仮想環境でのWindowsで確認されてたりしますか?
うちでも再現しませんでした。
いま、めちゃめちゃ速いのあるみたいですね。
SDSSDXPM2-1T00-J25
https://www.sandisk.co.jp/home/ssd/extreme-pro-m2-nvme-3d-ssd?utm_source=3dssd_1806&utm_medium=ya
クリエイター&ゲーマー向けの超高速SSD(seq Read 3400M/s)みたい。
処理速度が速いほど発生しやすいです。
一定時間内に見つけた検索結果をエディタに追加出力しますがその際の行数が一定以上だと出るのでそういう条件が出やすいファイルを作って検索すると再現しやすいと思います。
再現条件はスペックじゃない気がしています。
以下に確認に使ったSSDのベンチマーク結果を貼ります。
CrystalDiskMark 6.0.1 x64 (C) 2007-2018 hiyohiyo
Crystal Dew World : https://crystalmark.info/
-----------------------------------------------------------------------
* MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s]
* KB = 1000 bytes, KiB = 1024 bytes
Sequential Read (Q= 32,T= 1) : 523.641 MB/s
Sequential Write (Q= 32,T= 1) : 464.124 MB/s
Random Read 4KiB (Q= 8,T= 8) : 354.594 MB/s [ 86570.8 IOPS]
Random Write 4KiB (Q= 8,T= 8) : 284.225 MB/s [ 69390.9 IOPS]
Random Read 4KiB (Q= 32,T= 1) : 354.514 MB/s [ 86551.3 IOPS]
Random Write 4KiB (Q= 32,T= 1) : 280.880 MB/s [ 68574.2 IOPS]
Random Read 4KiB (Q= 1,T= 1) : 24.907 MB/s [ 6080.8 IOPS]
Random Write 4KiB (Q= 1,T= 1) : 54.189 MB/s [ 13229.7 IOPS]
Test : 1024 MiB [H: 19.4% (92.3/476.6 GiB)] (x5) [Interval=5 sec]
Date : 2018/07/01 12:04:11
OS : Windows 8.1 Pro [6.3 Build 9600] (x64)
チェック対象のコミットが違ってるかもしれないと思っています。
masterの最新版で確認してますが、masterでは再現しなかったりします?
正規表現検索で「^」を GREP するのが簡単です。もちろん対象ファイルが多い場所で。
この条件+masterで再現しました。
gitクローンの作業用に使ってるフォルダを指定したら出ました。
普通のSATA6G HDDです。ダイアログが交互に出て反応が鈍くなりました。
環境依存だと思いますが、リアルタイム表示OFFとキャンセルは操作可能でした。
普通のフォルダ内 grep では問題再現できませんでしたが、
一定時間内に見つけた検索結果をエディタに追加出力しますがその際の行数が一定以上だと出るのでそ> ういう条件が出やすいファイルを作って検索すると再現しやすいと思います。
test.zip
例えば上記のファイルを展開後に開いて、現在編集中のファイルから検索、をするとどうでしょうか? ファイル毎最初のみ検索 はチェックは外す必要があります。
これで再現成功しました!(喜んで良いのか微妙ですが)
master の Win32 Release で試しました。
ちなみに Win32 Debug だと途中で malloc が NULL を返して異常終了してました (´Д`)
自分の CrystalDiskMark 結果も置いておきます。
CrystalDiskMark 6.0.1 x64 (C) 2007-2018 hiyohiyo
Crystal Dew World : https://crystalmark.info/
-----------------------------------------------------------------------
* MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s]
* KB = 1000 bytes, KiB = 1024 bytes
Sequential Read (Q= 32,T= 1) : 2378.844 MB/s
Sequential Write (Q= 32,T= 1) : 422.632 MB/s
Random Read 4KiB (Q= 8,T= 8) : 542.169 MB/s [ 132365.5 IOPS]
Random Write 4KiB (Q= 8,T= 8) : 443.297 MB/s [ 108226.8 IOPS]
Random Read 4KiB (Q= 32,T= 1) : 198.133 MB/s [ 48372.3 IOPS]
Random Write 4KiB (Q= 32,T= 1) : 139.348 MB/s [ 34020.5 IOPS]
Random Read 4KiB (Q= 1,T= 1) : 15.624 MB/s [ 3814.5 IOPS]
Random Write 4KiB (Q= 1,T= 1) : 82.398 MB/s [ 20116.7 IOPS]
Test : 50 MiB [C: 96.1% (915.6/952.6 GiB)] (x2) [Interval=5 sec]
Date : 2018/07/03 15:54:44
OS : Windows 10 [10.0 Build 17134] (x64)
解決済みですか?
解決済みです。最新masterでも再現しないことを再度確認しましたのでクローズします。
自分の環境で走らせた結果です。
CrystalDiskMark 6.0.1 x64 (C) 2007-2018 hiyohiyo
KB = 1000 bytes, KiB = 1024 bytes
Sequential Read (Q= 32,T= 1) : 543.703 MB/s
Sequential Write (Q= 32,T= 1) : 501.757 MB/s
Random Read 4KiB (Q= 8,T= 8) : 391.025 MB/s [ 95465.1 IOPS]
Random Write 4KiB (Q= 8,T= 8) : 308.313 MB/s [ 75271.7 IOPS]
Random Read 4KiB (Q= 32,T= 1) : 383.109 MB/s [ 93532.5 IOPS]
Random Write 4KiB (Q= 32,T= 1) : 306.464 MB/s [ 74820.3 IOPS]
Random Read 4KiB (Q= 1,T= 1) : 34.619 MB/s [ 8451.9 IOPS]
Random Write 4KiB (Q= 1,T= 1) : 127.947 MB/s [ 31237.1 IOPS]
Test : 1024 MiB [D: 57.6% (257.6/447.0 GiB)] (x5) [Interval=5 sec]
Date : 2018/07/08 15:09:34
OS : Windows 10 Professional [10.0 Build 17134] (x64)
```

問題の現象のGIF動画です。
Most helpful comment
問題の現象のGIF動画です。