上書き保存に時間がかかる

[jinto_]

2019-03-12 20:09:28 Debug (64-bit)→Build: 2019-03-23 21:27:30 Debug (64-bit)に更新してみたら上書き保存に妙に時間がかかるようになったのですが、なにか変更があったのでしょうか。
例えばサンガツさんの風の呼ぶ声でざっくり比べてみると、２秒→５秒ぐらい差があります。
2019-03-24 13:13:59 Debug (64-bit)でやってみても同じでした。

[k4nagatsuki]

pull request #430の影響以外に心当たりが無いのですが、UIと保存が別のスレッドで行われるようになったので(ユーザの操作と保存処理が同時に行われるので保存処理が操作を妨害しない)、よほど古いCPUでもなければ理屈の上では保存の体感時間は速くなるはずです。

例外として、シナリオの圧縮処理を別スレッドで行う設定をオフにすれば、体感時間は遅くなる可能性があります。

そうでない場合は、原因がよく分かりませんが、バグで思いもよらない事が起きているという可能性もあります。ご使用の環境と、保存周りの設定がどうなっているかを教えていただけないでしょうか。

[jinto_]

そうですか。何か新しい処理でも入ったのかなと思えるような重さなのですが。
読み込みと保存の設定です。
多分デフォルトだと思います。

色々試してみるとwsnシナリオの場合、変わらないみたいです。

[k4nagatsuki]

実際に、ファイルを確実にディスクに書き込む処理が入っています。それによって突然停電が起きたような場合のデータ喪失を防ぐ事ができるというのがpull request #430です。

ただしその処理は別スレッドで行われるので、よほど古いCPUでもなければUI操作に影響は無いはずです。

CPU・ストレージなどの環境情報を教えてください。

[k4nagatsuki]

pull request #440

関係ありそうなところに手を入れてみました。少しよくなるかもしれません。

保存周りに手を入れているので、念のため、テスト版を試す前にシナリオのバックアップを取っておいてください。

どうしてもパフォーマンスがよくならない場合、「上書き時に更新されたファイルだけを保存する」オプションでかなり改善すると思います。

[jinto_]

こんなのでいいでしょうか。

[jinto_]

試してみたのですが、特に改善されたという感じはないですね。
「上書き時に更新されたファイルだけを保存する」にチェックを入れてもあまり変化は感じないです。

たぶん関係ないと思いますが、cwxeditor_error.logにこんなのがありました。

2019-03-24 21:03:44 [Build: 2019-03-24 20:43:39 Debug (64-bit)] cwx\utils.d:135 Stack Trace --------
cwx\editor\gui\dwt\mainwindow.d-mixin-4747, 4747
cwx\editor\gui\dwt\mainwindow.d-mixin-4750, 4750
cwx\editor\gui\dwt\directorywindow.d-mixin-1239, 1239
cwx\editor\gui\dwt\directorywindow.d-mixin-1250, 1250
cwx\editor\gui\dwt\directorywindow.d-mixin-1834, 1834
cwx\editor\gui\dwt\directorywindow.d-mixin-239, 239
cwx\editor\gui\dwt\directorywindow.d-mixin-241, 241
cwx\editor\gui\dwt\directorywindow.d-mixin-413, 413
cwx\editor\gui\dwt\directorywindow.d-mixin-430, 430
2019-03-24 21:03:44 [Build: 2019-03-24 20:43:39 Debug (64-bit)] cwx\editor\gui\dwt\directorywindow.d:289 [C:\Users\jinto\Downloads\CardWirthNext\Scenario\＠初\Ask\奇塊\~Battle2.wid: 指定されたファイルが見つかりません。] C:\Users\kkamei\root\devtools\dlang\dmd2\windows\bin\..\..\src\phobos\std\file.d, 2015: 0x00007FF70D4CA9F6
0x00007FF70D4CA83E
0x00007FF70D4CA744
0x00007FF70E648C7B
0x00007FF70E6241F7
0x00007FF70E63DBA2
0x00007FF70E636BB2
0x00007FF70F00C3FB
0x00007FF70EF9EE98
0x00007FF70EEE5DF9
0x00007FF70EEE3D08
0x00007FF70E6D4F89
0x00007FF70D557AFC
0x00007FF70F151A12
0x00007FF70F15182F
0x00007FF70F15193B
0x00007FF70F15182F
0x00007FF70F1515E1
0x00007FF70D5580E4
0x00007FF70F27758C
0x00007FF944B23DC4 in BaseThreadInitThunk
0x00007FF9471A3691 in RtlUserThreadStart

[k4nagatsuki]

CPUの型番を確認してみたのですが、4コアのようですね。少なくともコア数が少ないせいでスレッド分けが機能しないという事は無さそうです。

エラーの内容は、現在のバージョンでは生成されない一時ファイルに絡むものなので、たぶん今後は出ないと思うのですが、出ている理由がちょっと分かりません。以前の一時ファイルが残っていたのでしょうか？

「上書き時に更新されたファイルだけを保存する」の効果が無い、または薄いのも分かりません。このオプションが有効に機能しているなら、保存されるファイル数は減っているはずです。保存後に各ファイルの更新日時を確認していただけないでしょうか。

もし保存対象のファイル数が減っているのに保存時間に変化がない場合、そもそもファイルの保存以外のところで時間を食っているという事になりますが、それが何なのかは見当もつきません。そういう問題があるのであれば、ごく小さなシナリオでも同じ問題が起きるはずですが、実際に起きるでしょうか。

[jinto_]

2019-03-24 20:43:39 Debug (64-bit)で「上書き時に更新されたファイルだけを保存する」にチェックを入れて更新日時を見てみたら、特にチェックなしと変わらなかったです。
ただ、2019-03-12 20:09:28 Debug (64-bit)で見てみるといじったところだけ更新されてました。

ごく小さなシナリオ、例えばゴブリンの洞窟で比べてみると僅かですが遅くなっています。
これが奇魂ぐらいになるともっと分かりやすくなります。

どうも指定ファイル～は今でも出るようです。毎回ではないですが。

2019-03-25 18:11:22 [Build: 2019-03-24 20:43:39 Debug (64-bit)] cwx\utils.d:135 Stack Trace --------
cwx\editor\gui\dwt\mainwindow.d-mixin-4747, 4747
cwx\editor\gui\dwt\mainwindow.d-mixin-4750, 4750
cwx\editor\gui\dwt\directorywindow.d-mixin-1239, 1239
cwx\editor\gui\dwt\directorywindow.d-mixin-1250, 1250
cwx\editor\gui\dwt\directorywindow.d-mixin-1834, 1834
cwx\editor\gui\dwt\directorywindow.d-mixin-239, 239
cwx\editor\gui\dwt\directorywindow.d-mixin-241, 241
cwx\editor\gui\dwt\directorywindow.d-mixin-413, 413
cwx\editor\gui\dwt\directorywindow.d-mixin-430, 430
2019-03-25 18:11:22 [Build: 2019-03-24 20:43:39 Debug (64-bit)] cwx\editor\gui\dwt\directorywindow.d:289 [C:\Users\jinto\Downloads\CardWirthNext\Scenario\＠初\Ask\奇塊\~Area25.wid: 指定されたファイルが見つかりません。] C:\Users\kkamei\root\devtools\dlang\dmd2\windows\bin\..\..\src\phobos\std\file.d, 2015: 0x00007FF60923A9F6
0x00007FF60923A83E
0x00007FF60923A744
0x00007FF60A3B8C7B
0x00007FF60A3941F7
0x00007FF60A3ADBA2
0x00007FF60A3A6BB2
0x00007FF60AD7C3FB
0x00007FF60AD0EE98
0x00007FF60AC55DF9
0x00007FF60AC53D08
0x00007FF60A444F89
0x00007FF6092C7AFC
0x00007FF60AEC1A12
0x00007FF60AEC182F
0x00007FF60AEC193B
0x00007FF60AEC182F
0x00007FF60AEC15E1
0x00007FF6092C80E4
0x00007FF60AFE758C
0x00007FF944B23DC4 in BaseThreadInitThunk
0x00007FF9471A3691 in RtlUserThreadStart

[k4nagatsuki]

• pull request #441
• pull request #443

ご確認ありがとうございます。たぶんこれでだいぶ改善されると思います。

設定ファイルの更新時、他のプロセスに通知するためにファイル出力を待ち合わせていたのですが、シナリオの保存後に履歴を書くために設定ファイルを更新している事を失念していました。ですので、シナリオの保存時にファイル出力自体は別スレッドで行われるものの、設定ファイルの更新が行われたタイミングでファイルの出力待ちに入ってしまい、これが時間がかかる原因になっていたのだと思います。

「更新されたファイルを～」のオプションは、pull request #440でエンバグして機能しなくなっていました。それがオプションの効果が見られなかった原因と思われます。

[k4nagatsuki]

~*.widが存在しないというようなエラーが出る理由ですが、想像はついたものの確信できません。

過去のバージョンのcwxeditorがそのような名前で一時ファイルを作っているので、過去バージョンと同時にシナリオを開く事によってそういう問題が起きたというのが、一番ありえそうな原因です。

実際にそのような事をしていたのであれば、そのエラーログには説明がつきますが、そうでなければ原因不明です。

[jinto_]

直ってました。ありがとうございます。
それとエラーログの方もご推察の通りでした。
たまに前のverのと一緒に開いて、時間の差を見てる時がありました。
それではこれで解決とします。