4.0beta3,ファイル読み込み,読み込みバッ - 秀丸エディタβ版 - スレッド01800, 2003/06/18

4.0beta3,ファイル読み込み,読み込みバッ

izumi さん　03/06/18 00:52

タイトルが変ですが、許してください。

「カーソル行復元」の件を調査する際に気がついたのですが、
ファイル読み書き用のバッファについて、秀丸の場合、書き込みでは16384バイト単
位で処理しているようなのですが、
読み込みでは16352バイト単位のようです。
512バイトの整数倍にしていない理由が何かあるのでしょうか。

お手数をおかけしますが、ご回答いただけると幸いです。

Windows 2000sp3, Internet Explorer 6.0sp1, 秀丸 4.00beat3

RE:01800 4.0beta3,ファイル読み込み,読み

izumi さん　03/06/18 14:51

テンポラリファイルについても調べたところ、書き込み処理は8192バイト単位で行っ
ているようです。
512バイトの整数倍ではありますが、通常の書き込みバッファの半分しかないようです。

RE:01813 4.0beta3,ファイル読み込み,読み

秀まるお さん　03/06/18 16:38

　読み込みバッファは別として、テンポラリファイルについては、たしかに８キ
ロバイト単位でやりとりしてます。これはどうしてかというと、秀丸内部でのテ
キストファイルのテンポラリメモリ／ファイルへの分割単位が８キロバイト単位
だからです。

　この単位はメモリの利用効率を考えて決めた物で、初期の秀丸からずっと同じ
です。別にファイルへの書き込みバッファの単位に合わせたつもりは無いし、フ
ァイルへの書き込み単位に合わせればベストな物になるという、単純な物ではあ
りません。

--------
　読み込みについても、そもそもWindows側でバッファリングしてるだろうし、
CreateFileのオプションでFILE_FLAG_SEQUENTIAL_SCANも指定しているだろうし、
そんな細かいことまで気にしても性能に影響するとは思えないです。ハードディ
スク自体にもキャッシュメモリが２Ｍ～８Ｍもついてる時代に、シーケンシャル
アクセスのアクセス単位が８キロバイトだろうが１６キロバイトだろうが、ほと
んど違わないと思います。（試したことは無いけど）

RE:01818 4.0beta3,ファイル読み込み,読み

izumi さん　03/06/19 19:39

ご回答ありがとうございます。

> 　読み込みについても、そもそもWindows側でバッファリングしてるだろうし、
> CreateFileのオプションでFILE_FLAG_SEQUENTIAL_SCANも指定しているだろうし、
> そんな細かいことまで気にしても性能に影響するとは思えないです。ハードディ
> スク自体にもキャッシュメモリが２Ｍ～８Ｍもついてる時代に、シーケンシャル
> アクセスのアクセス単位が８キロバイトだろうが１６キロバイトだろうが、ほと
> んど違わないと思います。（試したことは無いけど）

私の書き込みで気分を害されているようですね。すみません。
ですが、しばらくお付き合いいただければ、と思います。

私事ですが、以前書いたコードに、データベースを解析してテキストで出力するもの
がありました。
このときの経験なのですが、飛び飛びの数バイトを読み込むときは、バッファリング
せず直接読み込む方が速いです。
しかし、あるまとまった単位で読み込むときは、なるべく多くのバイトを一括して読
み込む方が、全体としての応答時間は速かったのです。
# なるべく多く、とは言っても、物理メモリの残量は考慮する必要があるでしょう。
# 解析対象のファイルは、それほど大きくはありませんでしたので、正確な限界点は
わかりません。

この理由は簡単でした。解析処理部よりもディスクI/O(当時のディスクは5400rpm,キ
ャッシュは2MBでした)が遅かったのです。
私も当初は、OS(Win2K)がキャッシュするからバッファは不要、と判断していました
が、やってみると違いがはっきりわかりました。
HDDのキャッシュやOSのファイルキャッシュ機能は、OSや他のソフトも利用するため、
当てにできないのでしょう。

もし可能でしたら、騙されたと思って試してみてください。(^^;
(通常ファイルの)読み込みキャッシュを拡張すれば、単一プロセスの起動が高速にな
る可能性があると思います。
# HDDの音響制御機能を無効にしていれば、ディスクの音も変化するでしょう。
大容量のファイルでしか効果がわからないのですが、それほど無意味ではないと思い
ます。
(betaとして公開して、利用者の評価を募るという方法もありますよ。)

---
> 　読み込みバッファは別として、テンポラリファイルについては、たしかに８キ
> ロバイト単位でやりとりしてます。これはどうしてかというと、秀丸内部でのテ
> キストファイルのテンポラリメモリ／ファイルへの分割単位が８キロバイト単位
> だからです。
>
> 　この単位はメモリの利用効率を考えて決めた物で、初期の秀丸からずっと同じ
> です。別にファイルへの書き込みバッファの単位に合わせたつもりは無いし、フ
> ァイルへの書き込み単位に合わせればベストな物になるという、単純な物ではあ
> りません。

8192バイト単位である理由は、わかりました。ありがとうございます。
私も、通常ファイルの書き込みバッファ量と一致させる、ということが最善とは思い
ません。
ちょっと言葉が足りませんでしたね。すみません。

「バッファ」とは、緩衝装置として、処理能力の違いを吸収するためのもの、と認識
しています。
上記の経験から、ディスクはそれほど高速ではない、と私は考えていますので、
テンポラリファイルのI/Fにも、バッファが存在することを前提として考えていました。
つまり、通常のファイルもテンポラリファイルもバッファがある、という前提です。
その上で、本件は、これらのバッファサイズの決定理由を伺い、再考をお願いするも
のでした。

しかし、テンポラリファイルの場合、内部の処理単位がディスクインターフェースで
もそのまま使われているようですね。
テンポラリファイル用のバッファが存在するのかどうか、とは無関係に、
ご回答いただいた内容から、少なくとも内部仕様の制限を受けていることを感じます。
つまり、例え存在したとしても、緩衝機構として機能していない、と解釈しました。
あっているでしょうか?
もし、この認識があっているとすれば、テンポラリファイルに関するコードの変更は、
困難だろうと思います。
認識が間違っている場合は、非同期にサイズを変更できると思います。騙されたと思
って……、です。(^^;

---
バッファサイズを拡張すると、ディスクI/Oがボトルネックになっているシステムで
は、多少動作が速くなると思います。
検討していただけると幸いです。

RE:01869 4.0beta3,ファイル読み込み,読み

EMiCC さん　03/06/19 20:27

izumiさん、はじめまして。

横から口をはさんで申し訳ありません。

つまりizumiさんの言いたいことは、「大きなサイズのファイルの読み込みが遅いの
で、もっと早くして欲しい。
バッファとテンポラリファイルのサイズを見直せば速くなるのではないか」という要
望なのでしょうか？

RE:01872 4.0beta3,ファイル読み込み,読み

秀まるお さん　03/06/19 21:30

　細かい話はソースコードを公開しない限りわからないと思うので省略しますが、
たかがエディタといっても内部ではかなり面倒なことをしています。

　ただ、ファイルの読み込みについては、あまり詳しい検証をしたことがないの
で、その辺は暇をみて秀丸担当が調査するかもしれません。（僕の担当じゃない
ので）

RE:01873 4.0beta3,ファイル読み込み,読み

izumi さん　03/06/26 12:56

お返事が遅くなってしまい、申し訳ありません。

> 　ただ、ファイルの読み込みについては、あまり詳しい検証をしたことがないの
> で、その辺は暇をみて秀丸担当が調査するかもしれません。（僕の担当じゃない
> ので）

わかりました。
秀丸担当さん、調査のほど、よろしくお願いいたします。