C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

Re[7]: ファイルクローズのタイミング


(過去ログ 136 を表示中)

[トピック内 19 記事 (1 - 19 表示)]  << 0 >>

■80378 / inTopicNo.1)  ファイルクローズのタイミング
  
□投稿者/ さくらとあおい (16回)-(2016/07/12(Tue) 17:51:18)

分類:[VB.NET/VB2005 以降] 

すごく基本的な事をお聞きさせて頂きます。
VB.NETへ質問していますが、VCでも同じだと思いますので、
回答頂ければ幸いです。

以前、組込みマイコンと通信し、グラフをスクロールさせる方法を質問させて頂き、
動作するようになりました。

データを取得して、組込みマイコンのソフトデバックに使いたいと思っております。
10msec毎にデータを10個程度受信し、グラフを表示させていますが、
データをCSVファイルとして、保存したいです。

色々とサンプルを探して、お試しでCSVファイルにデータ書き込みは
できましたので、後は実際のソフトに落としこもうと思いましたが、
ファイルのクローズですが、書き込み後に毎回行うのと
保存終了時に行うのどちらが推奨でしょうか?

10msec毎にデータは受信しますが、グラフの更新はタイマー(100msec)で
行っていますので、100msec毎にCSVに追記していこうと考えています。

他の要因でデータ書き込みする可能性が考えられれば、書き込み後、クローズが
安全だと思いますが、このような書き込みだと、終了まではクローズ
しなくても良いのかなーと思っています。

保存終了ボタンをつける予定なので、これを押したらクローズ
すればよいのですが、フォームを閉じた時に、クローズできない可能性が
あり、この部分も別途質問させて頂こうと思っています。
フォームのクローズイベントでクローズさせればと思うのですが、
現在、うまくいってません。
引用返信 編集キー/
■80379 / inTopicNo.2)  Re[1]: ファイルクローズのタイミング
□投稿者/ 魔界の仮面弁士 (766回)-(2016/07/12(Tue) 18:30:32)
No80378 (さくらとあおい さん) に返信
> ソフトデバックに

BUG (バグ)をとるのは
debug (デバッグ)ですね。デバックではなく。


> このような書き込みだと、終了まではクローズ
> しなくても良いのかなーと思っています。

開きっぱなしで良いと思いますよ。
ただ、他のアプリからの書き込みを防ぐためのロック処理は必要でしょうね。
http://dobon.net/vb/dotnet/file/fileshare.html


CSV ファイル書き込み用の FileStream を用意し、
それを開く際に FileAccess.Write と FileShare.Read を指定すれば、
「自アプリからは書き込みを行える」
「他アプリは読み取りはできるが書き込みはできない」
という状態になります。

その上で、CSV データを吐き出し終わるたびに
Flush メソッドを呼び出すようにすれば良いかと思います。
引用返信 編集キー/
■80380 / inTopicNo.3)  Re[2]: ファイルクローズのタイミング
□投稿者/ 774RR (423回)-(2016/07/12(Tue) 18:33:23)
オイラなら、データ収集はオンメモリで行い(つまり測定開始時点ではファイルを開いたりしない)
保存する操作をしたときファイルを開いて書き込んで閉じる、とするかな。

測定中ずっとファイルを開いておくというのは無駄っぽい気がする。
引用返信 編集キー/
■80381 / inTopicNo.4)  Re[3]: ファイルクローズのタイミング
□投稿者/ furu (60回)-(2016/07/12(Tue) 18:46:52)
私だったら

途中経過を見たかったり、落ちた時も途中までの結果を見たいので
ファイルオープンしっぱなしのフラッシュにします。

100msec毎にファイル書込は多すぎるので
10秒(100回)に1回ぐらいでフラッシュする。

もしもの為、タイマで20秒間ファイル書込が無ければ
フラッシュする。
引用返信 編集キー/
■80382 / inTopicNo.5)  Re[4]: ファイルクローズのタイミング
□投稿者/ なちゃ (121回)-(2016/07/12(Tue) 19:30:52)
最後に保存するか、随時書き込むかは目的による(途中経過を見たいなら書き込みたいでしょうし)と思いますが、書き込む場合は毎回フラッシュで良いと思いますよ。
実用的にはフラッシュされてないと不便だったり困ったりしますし、パフォーマンス的な問題なら100ms毎のフラッシュは全然問題ありません。
※普通は遅延書き込みになり、ディスクに毎回物理フラッシュされるわけではない
引用返信 編集キー/
■80384 / inTopicNo.6)  Re[5]: ファイルクローズのタイミング
□投稿者/ furu (61回)-(2016/07/13(Wed) 10:11:03)
なちゃさん
私の勘違いかもしれません。教えてください。

> 書き込む場合は毎回フラッシュで良いと思いますよ。
> ※普通は遅延書き込みになり、ディスクに毎回物理フラッシュされるわけではない

フラッシュが遅延書き込で、物理フラッシュされるわけではないということでしょうか?
フラッシュはDBのCOMMITのようなもので、メソッドから戻った時にはディスク等への
書込が完了していると思っていました。

> パフォーマンス的な問題なら100ms毎のフラッシュは全然問題ありません。
1回のログの大きさにもよりますが、フラッシュの回数を減らせば、
ディスクへのブロック書込回数は減るから、PC全体の負荷は減ると思っています。
問題にならなければ、毎回フラッシュでもいいと思います。
引用返信 編集キー/
■80385 / inTopicNo.7)  Re[1]: ファイルクローズのタイミング
□投稿者/ とっちゃん (385回)-(2016/07/13(Wed) 10:49:43)
No80378 (さくらとあおい さん) に返信

ファイルの保存問題はもう出てるので、個人的には用途次第でしょ?なのでとりあえずスキップして...

> 10msec毎にデータは受信しますが、グラフの更新はタイマー(100msec)で
> 行っていますので、100msec毎にCSVに追記していこうと考えています。
>
0.1秒って画面更新頻度としてはかなり短い気がします。
で、ファイル保存処理と画面更新(グラフ作成)で合わせて0.1秒+0.01秒ごとにデータ追加ですよね?
うまく作らないと遅延発生 & データの取りこぼしという状況が出る可能性があります。


> 保存終了ボタンをつける予定なので、これを押したらクローズ
> すればよいのですが、フォームを閉じた時に、クローズできない可能性が
> あり、この部分も別途質問させて頂こうと思っています。
> フォームのクローズイベントでクローズさせればと思うのですが、
> 現在、うまくいってません。

Stream のクローズに失敗ではなく、クローズできない可能性というのはどういうものでしょう?
ボタンを押さずに画面を閉じてしまうということ?

であれば、保存終了ボタンを押したときの処理で、ストリームオブジェクトをきちんと開放するなら
それと同じ処理をクローズにも入れておいて、ストリームが閉じていたら何もしない
というようにすればいいと思います。

引用返信 編集キー/
■80386 / inTopicNo.8)  Re[6]: ファイルクローズのタイミング
□投稿者/ 魔界の仮面弁士 (767回)-(2016/07/13(Wed) 11:03:08)
2016/07/13(Wed) 11:04:54 編集(投稿者)

No80384 (furu さん) に返信
> なちゃさん
なちゃさんでは無いですが、私の認識している範囲で:


> フラッシュが遅延書き込で、物理フラッシュされるわけではないということでしょうか?

FileStream.Flush() だと、OS 側の I/O バッファまではフラッシュされませんが、
FileStream.Flush(flushToDisk:=True) ならば、FlushFileBuffers API を通じて
OS 側のバッファもフラッシュされます。

PC 負荷を抑えるなら、前者を使えば良いと思います。
障害発生時のデータ損失を抑えたいなら後者でしょうか。


また、FileStream のコンストラクタには、FileOptions.WriteThrough パラメーターを
指定することもできます。いわゆる FILE_FLAG_WRITE_THROUGH ですね。(試した事はありません)

【KB410193】[SDK32] FILE_FLAG_WRITE_THROUGH と FILE_FLAG_NO_BUFFERING
https://support.microsoft.com/ja-jp/kb/410193



> フラッシュはDBのCOMMITのようなもので、
> メソッドから戻った時にはディスク等への書込が完了していると思っていました。

少なくとも Access mdb の コミット処理はそうではありません。
Jet エンジン自体のキャッシュ機構もありますが、それとは別に
OS の Write Cache の影響を受けるため、若干の遅延書き込みが発生します。

一応、OS のキャッシュをバイパスする手段も用意されており、具体的には
DAO の CommitTrans メソッドで dbForceOSFlush パラメータを指定するか、
ADODB の Connection オブジェクトに対して "Jet OLEDB:Transaction Commit Mode" という
ダイナミック プロパティを 1 に設定することで対処できるようにはなっています。


一方 SQL Server の場合は、ログおよびデータ ファイルは CreateFile の
dwFlagsAndAttributes にて FILE_FLAG_WRITE_THROUGH が指定される仕様ですね。

【KB234656】INF: SQL Server でディスク ドライブのキャッシュを使う。
https://support.microsoft.com/ja-jp/kb/234656
※上記は SQL Server 7.0 の情報ですが、その後のバージョンも同様だそうで。



> 1回のログの大きさにもよりますが、フラッシュの回数を減らせば、
> ディスクへのブロック書込回数は減るから、PC全体の負荷は減ると思っています。

今は亡き FDD などの低速デバイスだと、OS の Write Cache の有無で
かなり差が出そうですね。100ms 間隔の書き込みだと追いつかないかも。
引用返信 編集キー/
■80387 / inTopicNo.9)  Re[6]: ファイルクローズのタイミング
□投稿者/ なちゃ (122回)-(2016/07/13(Wed) 12:11:46)
No80384 (furu さん) に返信
> なちゃさん
> 私の勘違いかもしれません。教えてください。
>
>>書き込む場合は毎回フラッシュで良いと思いますよ。
>>※普通は遅延書き込みになり、ディスクに毎回物理フラッシュされるわけではない
>
> フラッシュが遅延書き込で、物理フラッシュされるわけではないということでしょうか?
> フラッシュはDBのCOMMITのようなもので、メソッドから戻った時にはディスク等への
> 書込が完了していると思っていました。
>
>>パフォーマンス的な問題なら100ms毎のフラッシュは全然問題ありません。
> 1回のログの大きさにもよりますが、フラッシュの回数を減らせば、
> ディスクへのブロック書込回数は減るから、PC全体の負荷は減ると思っています。
> 問題にならなければ、毎回フラッシュでもいいと思います。

魔界の方が説明してくださってるのでそんなに追加することはないのですが。
一言でフラッシュといっても、実際にはいろんなレイヤがあります。
FileStreamやStreamWriterなどのフラッシュは、基本的に.NETのAPIレイヤでのフラッシュで、Win32APIのWriteFileを呼ぶところまでになります。
ちなみに魔界の方が照会された引数を持つFlushメソッドは、.NET4だったかあたりで追加されたもので、それまでは物理フラッシュするメソッド等はありませんでした。
※ちなみにファイルをクローズしても物理フラッシュされません。

WriteFileはデータをキャッシュに書き込むだけでフラッシュは行いません。
キャッシュに書き込まれたデータは、OSのキャッシュマネージャによって適当なタイミングで非同期にデバイスに書き込まれます。

プログラムからのフラッシュはどうしても物理フラッシュが必要な場合以外は、通常のフラッシュで十分です。
OS上経由のファイルアクセスではフラッシュ済みに見えますので、停電などの問題以外では基本的に不都合は起きません。
引用返信 編集キー/
■80388 / inTopicNo.10)  Re[2]: ファイルクローズのタイミング
□投稿者/ なちゃ (123回)-(2016/07/13(Wed) 12:17:04)
ちなみに余談ですが、ディスクのプロパティだったかあたりで、拡張パフォーマンスだったかいう設定を有効にすると、OSの物理フラッシュすら無効になります。
※昔のバグの互換性のための設定
引用返信 編集キー/
■80389 / inTopicNo.11)  Re[3]: ファイルクローズのタイミング
□投稿者/ 774RR (424回)-(2016/07/13(Wed) 13:40:37)
物理フラッシュできたとしても、データが1セクタ(っつかクラスタっつか)に満たない量しかないと
いたずらに処理量が増えるだけで実用的でない (SSD の寿命を縮めることにもなりかねない) 。
データベース系のソフトはそういう管理まで皆自分でやった上で WRITE_THRU なり NO_BUFFERING を指定してるので
普通にデバイスからデータ収集するだけなら Stream なんちゃらレベルの Flush で十分に1票。

# オイラの意見は当初のまま、一括書き出しのほうが面倒が無くてよい、ですけど。

オイラも、ファイルを閉じることができないかも?ってあたりが気になるけど
別質問を挙げるということなのでとりあえず静観。
もしそういう状況に陥る(ってか既に陥っている)のであれば、それはバグだし、
バグならばデバッグすればよいだけだと思うが。

引用返信 編集キー/
■80392 / inTopicNo.12)  Re[4]: ファイルクローズのタイミング
□投稿者/ さくらとあおい (17回)-(2016/07/13(Wed) 18:45:04)
皆様回答ありがとうございます。
朝確認した時に5件の回答でしたので、長い会議の後に
個別に回答させて頂こうと思いましたが、今見たら10件以上なので
こちらにまとめて、回答させて頂きます。

まず、途中経過に関しては、グラフや数値表示を行っていますので
それで確認できれば充分と思っています。

組込みマイコンの制御動作(指令を与えてその時のセンサーの値)を確認
したいので、おおざっぱな動作はグラフ等を確認し、あとでCSVファイルを
エクセル上で、グラフにして検証したいというのが目的です。
(指令を与えてどのくらいの時間で変化するや、センサーの値が
どの程度ずれているか等、細かい値を確認。)

回答をまとめますと、
・ファイルクローズは最後でよい
・一括書き出しがよい
・100msecだと短い、問題ない
 ※漏れがございましたら失礼しました

皆さんが想像されているより、かなり初歩的な書き込み方法を想定しています。
例えば、3種類のデータを書き込む場合、下記を考えています。

textLine = CStr(i1) + "," + CStr(i2) + "," + CStr(i3)
textFile.WriteLine(textLine)

これが10msec分ですので、100msec分にして書き込み
しようと思ってます。

エクセルでグラフにしたいので、データ数(縦)は30000以下がよいと
思いますので、時間にしては300秒とかになりますので、
一つの動作を確認する場合に、長くても30秒程度でよいので
一括なり、10秒毎の保存でも良いかもしれないですね。

最初の質問でフォームクローズ時にファイルをクローズできないは、
宣言の仕方に問題があり、解決しました。

この流れで恥ずかしい質問なのですが、フラッシュってこの内容で
初めて聞くワードでネットで調べてなんとなくはイメージできたのですが、
CSVファイルや他のファイル書き込みで関連するのが分かる
HPとかご存知でしたら教えて頂けないでしょうか?

あと、根本的にデータ保存のやり方が上記の方法だと大量データでは
厳しいでしょうか?

引用返信 編集キー/
■80393 / inTopicNo.13)  Re[5]: ファイルクローズのタイミング
□投稿者/ 774RR (425回)-(2016/07/14(Thu) 09:40:45)
何がわかっていなくて何が聞きたいのかはっきりしないけど

flush とは押し流すの意味。トイレの水を流す行為が flush 。
(フラッシュメモリは flash 閃光的短時間でデータを消す、書き込む、ができるの意味)

ディスク装置はおよそコンピュータの中で最も遅い装置なので、これに足を引っ張られぬよう
ディスク装置に対する実操作を最小限に留めるため、いろんな層に cache [隠し場所] が設けてあるのが普通。
# cache は隠し場所、現金は cash で違う単語、読みはほぼ同じでキャッシュ

cache は Stream 層にもあるし OS 本体にもあるしデバイスドライバにもあるしディスク装置自体にもある。
その [隠し場所] に隠してあるデータを押し流す行為が flush 。
書き込み側 flush は、途中に隠してあるデータをディスク装置に流し込むの意味。
読み込み側 flush は、途中に隠してあるデータを捨てて再度ディスク装置から読み取るの意味。

CSV って要するにただのテキストファイルだから [CSV 固有のどうこう] は無くて、
テキストファイルの入出力一般論で十分だよ。

大量データってのがどのくらいの量なのかで話は違うけど
今時なら キロバイト 単位のデータは大量ではないので何も気にすることは無い。
Excel で 30000 行の CSV だったらせいぜい 300 キロバイトも行かないだろうし。

メガバイト以上のテキストファイルとなるとエディタによる編集も困難だし、
そういう場合はデータを複数のファイルに分割して保存するなどの工作が必要だろう。

引用返信 編集キー/
■80394 / inTopicNo.14)  Re[5]: ファイルクローズのタイミング
□投稿者/ 魔界の仮面弁士 (768回)-(2016/07/14(Thu) 10:04:09)
No80392 (さくらとあおい さん) に返信
> エクセルでグラフにしたいので、

Excel で CSV を直接開いた場合、ブックを閉じるまで
ファイルが開いたままになる実装です。

ですから Excel 側では、読み取り専用モードで開くか、
あるいはファイルを直接開くのではなく、インポートするなどの
対処が必要になるかも知れません。

今回の場合は、Excel の「外部データの取り込み」を用いて
CSV にリンクしたワークシートを用意するのが良いかもしれませんね。


あるいは、VB 側でグラフ生成まで行う手もあるかと思いますが、
本題からは外れるので割愛。


> textLine = CStr(i1) + "," + CStr(i2) + "," + CStr(i3)
> textFile.WriteLine(textLine)

1行ずつの出力なのですね。それ自体は問題ないと思います。

ただ、VB の文字列連結では、「+」ではなく「&」を使うことをお奨めします。
http://www.grapecity.com/tools/support/powernews/articles/column/string_class.htm
引用返信 編集キー/
■80395 / inTopicNo.15)  Re[6]: ファイルクローズのタイミング
□投稿者/ さくらとあおい (18回)-(2016/07/14(Thu) 10:54:49)
No80393 (774RR さん) に返信

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

> cache は Stream 層にもあるし OS 本体にもあるしデバイスドライバにもあるしディスク装置自体にもある。
> その [隠し場所] に隠してあるデータを押し流す行為が flush 。
> 書き込み側 flush は、途中に隠してあるデータをディスク装置に流し込むの意味。
> 読み込み側 flush は、途中に隠してあるデータを捨てて再度ディスク装置から読み取るの意味。

フラッシュメモリは知っていますが、この手の処理を行う際に
フラッシュという用語がどのような動作を指すのか、もしくは
なんらかの命令や処理の事を指すのかが理解できませんでした。

一般的な書き込みを指すのではなく、キャッシュとディスク装置間のアクセスと
いう事でよいでしょうか?

> CSV って要するにただのテキストファイルだから [CSV 固有のどうこう] は無くて、
> テキストファイルの入出力一般論で十分だよ。

CSVがテキストファイルは理解しています。
VBでテキストファイル処理自体をこれから習得なのですが、
結果的にCSVファイルにするので、CSVで質問させて頂きました。

エクセルでグラフにしたいので、データ数は30000くらいまでにしたいと
思ってますし、あるタイミングの時(5秒程度)のデータを見たいので、
事象と計測開始、終了を含めて充分な時間かと思います。

引用返信 編集キー/
■80396 / inTopicNo.16)  Re[6]: ファイルクローズのタイミング
□投稿者/ さくらとあおい (19回)-(2016/07/14(Thu) 11:05:48)
No80394 (魔界の仮面弁士 さん) に返信

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

> Excel で CSV を直接開いた場合、ブックを閉じるまで
> ファイルが開いたままになる実装です。
>
> ですから Excel 側では、読み取り専用モードで開くか、
> あるいはファイルを直接開くのではなく、インポートするなどの
> 対処が必要になるかも知れません。

データ通信時は、VB上で数値とグラフを表示し、
その後に、詳細な確認をする為に、エクセル上でデータを見ますので
データ書き込みとエクセルで開くは、同時にアクセスは
考えていません。
もし、長時間データを保管する事になって、データを確認する
必要がある場合は、書き込み中のデータをコピーして、コピーした
ファイルを開けばよいかと思ってます。

>>textLine = CStr(i1) + "," + CStr(i2) + "," + CStr(i3)
>>textFile.WriteLine(textLine)
>
> 1行ずつの出力なのですね。それ自体は問題ないと思います。

これは、お手本の内容をベースにして1行書き込みなので、
ライトの前に複数行を1つのテキストにして、書き込む様に
変更します。
作成前にファイルのクローズで疑問があり質問した次第です。

皆様がフラッシュと書かれているので、書き込み方法の
手段を言われているのかと思いましたが、これでも問題ないとの
事で安心しました。
難しいやり方をいきなり行うと、途中で大変になりそうなので。


> ただ、VB の文字列連結では、「+」ではなく「&」を使うことをお奨めします。
> http://www.grapecity.com/tools/support/powernews/articles/column/string_class.htm

&の方が可読性が良いので推奨という事は勉強になりました。
(すぐには、なじめないですが・・・)

引用返信 編集キー/
■80397 / inTopicNo.17)  Re[7]: ファイルクローズのタイミング
□投稿者/ さくらとあおい (21回)-(2016/07/14(Thu) 14:59:42)
色々とご提案のあった方法のどちらでも、CSVファイルの書き込みができました。

【100msec毎に書き込み】

10msec毎のデータに分割した際に、下記を実行
textLine = CStr(i1) + "," + CStr(i2) + "," + CStr(i3)
textFile.WriteLine(textLine)

理論的には100msec/10msec=10回繰り返すが、
マイコンとPCのタイマーの誤差があるので、9〜11回
繰り返す。

【最後に書き込み】

10msec毎のデータに分割した際に、下記を実行
textLine = textLine + CStr(i1) + "," + CStr(i2) + "," + CStr(i3) + vbCrLf
9〜11回繰り返し、フォームを閉じる時に、
textFile.WriteLine(textLine)を実行し、クローズする

解決済み
引用返信 編集キー/
■80398 / inTopicNo.18)  Re[7]: ファイルクローズのタイミング
□投稿者/ 魔界の仮面弁士 (769回)-(2016/07/14(Thu) 15:02:16)
No80396 (さくらとあおい さん) に返信
> これは、お手本の内容をベースにして1行書き込みなので、
> ライトの前に複数行を1つのテキストにして、書き込む様に
> 変更します。


随時出力であれば、データ件数が増えてもさほど低速化はしないのですが、
一括出力するのであれば、StringBuilder を使うことをお奨めします。

書き込みに時間がかかるストレージの場合、一括出力は高速化の効果がありますが、
そのための文字列連結に時間がかかってしまうようだと、むしろ逆効果になります。

先に紹介した URL でも触れられていますが、
単純な文字列連結だけで処理してしまうと、
メモリの再確保・転送・解放のための時間が余計にかかり、
行数に対して処理時間が加速度的に増加することになります。



Public Class Form1
  '同じデータを10万行出力する
  Private Const LineCount = 100000

  ' 文字列連結。当方環境では 21.56秒。
  Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
    Dim st = Stopwatch.StartNew

    Dim appendLine As String = "1,2,3" & vbCrLf

    Dim csv As String = ""
    For n = 1 To LineCount
      csv &= appendLine
    Next
    System.IO.File.WriteAllText("C:\TEST\SAMPLE1.CSV", csv)

    st.Stop()
    Button1.Text = st.Elapsed.ToString
  End Sub

  ' 随時出力。当方環境では 0.012秒。
  Private Sub Button2_Click(sender As Object, e As EventArgs) Handles Button2.Click
    Dim st = Stopwatch.StartNew

    Dim appendLine As String = "1,2,3"
    Using sw As New System.IO.StreamWriter("C:\TEST\SAMPLE2.CSV")
      For n = 1 To LineCount
        sw.WriteLine(appendLine)
      Next
      sw.Close()
    End Using

    st.Stop()
    Button2.Text = st.Elapsed.ToString
  End Sub

  ' StringBuilder による連結 & 一括出力。当方環境では 0.008秒。
  Private Sub Button3_Click(sender As Object, e As EventArgs) Handles Button3.Click
    Dim st = Stopwatch.StartNew

    Dim appendLine As String = "1,2,3"

    Dim csv As New System.Text.StringBuilder()
    For n = 1 To LineCount
      csv.AppendLine(appendLine)
    Next
    System.IO.File.WriteAllText("C:\TEST\SAMPLE3.CSV", csv.ToString())

    st.Stop()
    Button3.Text = st.Elapsed.ToString
  End Sub
End Class

引用返信 編集キー/
■80399 / inTopicNo.19)  Re[8]: ファイルクローズのタイミング
□投稿者/ さくらとあおい (23回)-(2016/07/14(Thu) 18:02:41)
No80398 (魔界の仮面弁士 さん) に返信

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

> 随時出力であれば、データ件数が増えてもさほど低速化はしないのですが、
> 一括出力するのであれば、StringBuilder を使うことをお奨めします。

現時点では特に低速化は気になってませんが、
StringBuilder を知る機会ができてありがとうございます。

> 書き込みに時間がかかるストレージの場合、一括出力は高速化の効果がありますが、
> そのための文字列連結に時間がかかってしまうようだと、むしろ逆効果になります。
>
> 先に紹介した URL でも触れられていますが、
> 単純な文字列連結だけで処理してしまうと、
> メモリの再確保・転送・解放のための時間が余計にかかり、
> 行数に対して処理時間が加速度的に増加することになります。
>

ごもっともですし、わざわざ実測までして頂いてありがとうございます。

かなり昔にマイクロソフトCで同じようなアプリを作るときは、
そんなに手段が多くなかったと記憶していますが、今はソフトのロジックを
考えることよりも、このような手段を調べる方に時間がかかります。

色々とありがとうございます。
他の方もアドバイスありがとうございました。
引用返信 編集キー/


トピック内ページ移動 / << 0 >>

このトピックに書きこむ

過去ログには書き込み不可

管理者用

- Child Tree -