このフォルダでのメールの発生順No.02839
Iranoan さん　10/01/30 14:08
　
　秀まるおさん今日は、Iranoan です。
　今頃気が付いたのですが、メール一覧の表示方法を、「このフォルダでの
メールの発生順」にしていると、他に比べて時間がかかりますね。(勿論、起
動後最初に表示した時だけですが)
　待ちくたびれたり、イライラするほどではないですが、他のが速いだけに、
不思議です。ソートの必要がないので、一番時間がかからない気もするのです
が...。(第二ソート・キーとの兼ね合いもある???) また list.bin を使って
いるでしょうから、ソート方法に依存しない気もするのですが、どうなので
しょう?
　余分な処理をして、ボトル・ネックが発生しているいないかが、少し気にな
ります。
　こちらの環境は、WindowsXP+IE8.0+秀丸メール Ver. 5.33beta5 です。
[ △ ]
RE:02839 このフォルダでのメールの発生順No.02841
秀まるお さん　10/01/30 23:32
　
　「このフォルダでのメール発生順」にすると、メール用ファイルの「作成時
刻」、つまり、WIN32_FIND_DATA中のftCreationTimeで比較するようになります。
なので、ファイル数が非常に多いと極端に遅くなるのだと思います。

　ftCreationTimeの値をうまくキャッシュして比較するようにすれば高速になる
と思いますけど、そこまで手の込んだ処理は作ってないです。

　ftCreationTimeじゃなくてftLastWriteTimeの方だったら、実は秀丸メールは
常にメモリ上にキャッシュしてるんですが、これで比較すると、ユーザー様の期
待した順序になってくれないです。

　ということで、現状、メール数が多ければ多いだけ遅くなり、しかも
FindFirstFileが遅い場合（ネットワークドライブ上にメールデータがある場合
とか）だとなおさら遅いようではあります。

　具体的に、メール数が何通で何秒かかるとか、Iranoanさんの所でどんなもん
か教えていただければ、それによっては無理してでも高速化しますけども…。

　僕の所で試した限りでは、例えば秀丸メールサポート会議室の３万８千通の
メールがあるフォルダでメール発生順ソートした場合に、１秒かかりません。も
しかして検索フォルダとかでソートさせると遅いかもしれないですけど…。

　それと、忘れてましたが、僕のメールアカウントは、「アカウント毎の設定・
使用状況」の所の「断片化されたメール用ファイルを結合する」を押して効率い
い状態にしてしまってました。なので速いのかもしません。

　それと、僕のマシンはCPUがAthlonXP 1250MHz、メモリ512M、ウィルスバス
ター2010のお試し版が入った状態です。ハードディスクは2.5インチ60Gのパラレ
ルATAのやつです。

--------------------------------------------------
　ソートとか、スレッド表示の生成速度とか、その他いろいろ、僕はストイック
なくらいに高速化をやってるつもりではあります。他のメールソフトとかと比較
して遅い所があったら遠慮無く連絡して欲しい所です。
[ △ ]
RE:02841 このフォルダでのメールの発生順No.02842
秀まるお さん　10/01/31 00:01
　
> 　ソートとか、スレッド表示の生成速度とか、その他いろいろ、僕はストイック
> なくらいに高速化をやってるつもりではあります。他のメールソフトとかと比較
> して遅い所があったら遠慮無く連絡して欲しい所です。

　強気なことを書いてしまいましたが、やっぱり取り消しさせていただきます。
遅い所は遅いので…。

　今さら思い出しましたが、検索フォルダなんかはデータ形式的な互換性を考え
ると、あんまり高速じゃないです。それと、いわゆる普通の検索も、googleとか
namazuみたいなインデックス方式の検索は出来ないので遅いし…。

　インデックス方式は…。僕の力ではまだまだ無理そうです。
[ △ ]
RE:02842 このフォルダでのメールの発生順No.02843
Iranoan さん　10/01/31 01:22
　
　秀まるおさん今日は、Iranoan です。
> ３万８千通の
> メールがあるフォルダでメール発生順ソートした場合に、１秒かかりません。
と比べてみると、遅すぎるので、いろいろ試してみると、私の環境の問題でした。

　具体的には、ファイアーウォール付いていたソフトの動きを監視するソフト
(Comodo Firewall に付いている Diffence+) が原因でした。

　他のソート方法が素早かった為に、却ってその手のソフトウェアを疑ってい
ませんでしたm(_|_)m。
[ △ ]
RE:02841 このフォルダでのメールの発生順No.02844
Iranoan さん　10/01/31 13:19
　
　秀まるおさん今日は、Iranoan です。
　問題は私の環境という事は解ったのですが、ちょっと確認させて下さい。

> WIN32_FIND_DATA中のftCreationTimeで比較するようになります。
　という事は、「バックアップのお手伝い」を使った場合も含めて、メール・
ファイルをコピーする処理があると、ソートが狂う事がありますか?

> 　ftCreationTimeの値をうまくキャッシュして比較するようにすれば高速になる
> と思いますけど、そこまで手の込んだ処理は作ってないです。
　私の使用環境でも、ディスク・アクセスが list.bin に限定されて速くなり
ますね。しかし、キャッシュ (list.bin) が何かの原因で破壊され、再生制さ
れる可能性を考えると、上記の事には関係ないですし。
　ftCreationTime は 100 ns 単位なので、「バックアップのお手伝い」の処
理時に、ftCreationTime の値が小さい順にコピー時していれば、実用上問題
ないでしょうけど。

                                      ................
　##今まで、新しいファイルだけ (普通に順番を気にしないで) コピーする事
で、バックアップを取っていたけれど、日付情報正しく扱えるアーカイバで一
度圧縮しないとまずいかな〜。
[ △ ]
RE:02844 このフォルダでのメールの発生順No.02846
秀まるお さん　10/01/31 15:22
　
> 　という事は、「バックアップのお手伝い」を使った場合も含めて、メール・
> ファイルをコピーする処理があると、ソートが狂う事がありますか?

　狂うということは無いんですけど、メールデータの発生順序として、移動／
コピー元のメール発生順がそのまま移動／コピー先に引き継がれる可能性は低
いです。

　あくまでそのフォルダ上でのメール発生順ということになるんですけど、秀
丸メール内部でのメール移動／コピーする時の、「どのメールから順番に処理
するか」というのは、特にユーザー様に保証出来るようなルールは無いです。

　ただし、移動／コピーした順番として、例えば昨日コピーして、今日またコ
ピーしたら、今日コピーされたメールの方が発生順は後になるはずです。
[ △ ]
RE:02846 このフォルダでのメールの発生順No.02848
Iranoan さん　10/01/31 15:59
　
　秀まるおさん今日は、Iranoan です。
> 　あくまでそのフォルダ上でのメール発生順ということになるんですけど、秀
> 丸メール内部でのメール移動／コピーする時の、「どのメールから順番に処理
> するか」というのは、特にユーザー様に保証出来るようなルールは無いです。
　やはりそうですか。メール・ファイルとして、
ファイル名        更新日時              更新日時の順序
A             2010/01/28  12:00:00.0      古い
B             2010/01/29  12:00:00.0      新しい
が有った時に、移動は作成日時が保持されるので良いですが、纏めてコピーし
た時に、B, A の順でコピーされ
ファイル名        更新日時              更新日時の順序
A             2010/01/31  15:51:00.0      新しい
B             2010/01/31  15:50:59.0      古い
となり、順序が変わってしまう事はあり得るわけですね。

　かといって今の仕様より良い方法も無さそうなので、致し方ないですね。
　自分で使い方を工夫する様にします。

　どうも有り難うございました。
[ △ ]