経緯
数10nsの世界のオシロの波形を数秒以上取ると、すぐにMB単位の巨大なログデータになってしまい、csvファイルから毎回読み込んで全部の点を線分として描画するのは、メモリリソースや処理負荷的によろしくない。とか色々考えたことをメモとして残しておく。
やったことなど
csvファイルの読み込みとログデータの変換
普段だと、テキトーなツールを使うときは
Regexr=newRegex(@"^ほげほげ・・・$");string[]lines=File.ReadAllLines(fileName);foreach(stringsinlines){string[]t=s.Split(newchar[]{',');for(inti=0;i<t.Length;i++){Matchm=r.Match(t[i]);：：}：：}みたいなコードを息を吐くように書いてますが、ファイルがでかいと数秒以上待たされる。ASCIIデータであっても地味に内部で文字コード変換が行われるので、メモリもファイルサイズの2倍くらいは使っていそう。
そこで、取りうる手段を考える。
- 描画するときに必要な部分をcsvファイルから都度読み出す。
⇒ 1行あたりのデータが固定長でない（値に依存して文字列の長さが変わる）ようなcsvファイルだったので、所望の要素番目のデータへのシーク（ランダムアクセス）が困難（ファイルの頭から毎回読むか、目次データ的なテーブルを持つ羽目になる）。廃案。 - 一旦読み込んで、1要素 = float型1個分のデータなどの変換を施して、固定長レコードの別ファイルに変換しておく。・・・これを採用した。(
BinaryWriterクラスでごにょごにょ)
オシロ風のグラフ描画処理
10万とか100万要素もあると、DrawLineとかで処理すると処理負荷が無駄にかかる。
かといって、データを間引きして描画すると、オシロ波形上のヒゲなどを取りこぼしてしまい、見落としにつながる。
ということで、画面横幅のピクセル数以上の要素数を持つときは、全要素を線分でつなぐような描画はせず、処理を切り替える。
具体的には、画面（というか描画先のBitmap）の1つのx座標(1ピクセル)に属す要素たちを1つの単位として扱い、その要素たち（区間）の最小値と最大値を求め、それらをPointの配列としてFillPolygonで塗りつぶすようにした。（単位といっても、とくにclassとかは使わずに単純にfor文の開始と終了のインデックスをうまいこと計算して処理した。）
FillPolygonとPoint配列のindexは工夫が要る。MAXの系列の左端をPoint配列のindex = 0, 1, 2, ... , N-1の要素として扱い、MINの系列の左端をindex = 2N-1, 2N-2, ... , Nとして扱った。FillPolygonだけだと塗りつぶし領域に太さがないと描画されない現象が出たので、DrawLinesを併用して輪郭も描画して対策した。
久々のオーバーフロー
C#のint型は32bitで、その正の数の最大値は 2,147,483,647 なので、46000ちょいの値同士を掛け算するなどで簡単にオーバーフローしてしまいます。巨大な配列の添え字をごにょごにょするときは、とりあえずlong型を使いまくる。
C#ではchecked{}でくくると例外吐いてくれるので、開発途中は付けておいたほうが無難。（それだけを担保にしてはいけないが。）
ちなみに、unsafe{}外でも、配列範囲外アクセスしたときに例外で落ちないケースがある気がするが、そういうものなのか、気のせいなのか・・・？
まとめ（？）
- 気にすることは使用メモリ量と処理時間・・・だけど利便性も残す。
- 規模が大きくなると処理方式（アルゴリズム）やデータ構造を考え直す必要がでてくる。初めからどの程度の規模のデータを扱うかは考慮しておいたほうがよい。オーダーの概念やキャッシュの概念などは知っておいたほうがよい。
- とはいえ、実感がわかないし予測もムズカシイので、簡単なアルゴリズムベースでプロトタイピングをして、ユーザビリティを感覚的に試すのもアリ。（簡単に試せる環境があれば。）
- オーバーフローやら配列の要素数の限界やら、数の許容範囲を気にする必要がでてくる。