中央競馬の予想や購入したもののメモなどを書いて行こうかと。まあ、個人的なメモ的なブログです。
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
JRA-VANの掲示板でのやり取りで、14時間とかは問題外の遅さorz いや、別にスピードスターだとは思ってなかったけど、少し内容は違うかもだが、同じ事を30分で可能な事を14時間越えってのはねぇ。
まあ、手抜きコーディングなのは否めなくて、少し反省も含め、手を打つ事にしたのですが、これがまあ、非常に手間の掛かる作業ではありました。全テーブルへのデータ登録時の元データの処理を書き直しです。ここまでデータ提供先提供のモジュール利用して、手抜きしてたんですが、これ使わずに直にバイト配列から位置と長さ指定してデータベース登録データの指定する様に書き直す事にしました。この作業を先週夜勤明けに毎日こなして、ある程度デバッグも済ませてました。土曜日朝の夜勤明けに最後のデバックも済ませて、もう何度目かは全く把握してないフルセットアップを何とか日付変わった1時にスタートして寝ました。朝起き昼頃には終わるな~っと、昼頃の最後の段階見て愕然とした。いや、普通にバグが残ってたのは別にねぇ、自分が完璧じゃないのは驚く事ではないけど、14時間近くやった後にエラー見ると流石に辛い。
人間が作業すれば必ずヒューマンエラーがあるんですが、これが年齢的にも酷い^^; チェックしてるつもりも抜けてるなんてのは当たり前ですね。更に、今回はSQLite3の接続時の指定での効率アップも少し期待してます。ここまでは、そもそもコードファーストでEntity Framework使って楽にデータベース処理とはじめたのにコードファーストでのDBファイル作成は出来てますが、エンティティからの楽々データ登録はあまりの処理速度の遅さで採用断念し、現在のSQLを投げるものに変更する時にも膨大な時間とヒューマンエラーのデバック。コードファーストでのDB接続だったので、接続文字列なんかの知識も全く無い状態でしたので、
synchronous=off
journal mode=wal
locking_mode=exclusive
temp_store=memory
mmap_size=30000000000
を指定すると良いよってアドバイスを受けました。しかし、System.Data.SQLite.Coreでは上2つは指定方法が見つかりましたが、下3つは不明。2つ追加した状態で19時過ぎに再びフルセットアップ開始したので、明日中番の出勤前には結果が分かるかな~っと。
このPC、昨夜も夜通し動かしてましたが、今晩もこのまま行く予定です。頑張れ~!
データベース登録済みのデータ表示にDataGridViewコントロールを利用してみる事にしたのですが、最初はデータバインディングで楽にと思ってましたが、これがそうでもなく、データバインディングせずに自力でデータ表示する事にしました。
デザイン時にカラムのタイトルや幅の指定をしてたんですが、これが挙動がおかしくて苦労させられました。デザイン時に列の編集からしても、実行して諸々してると勝手に幅が変わる。そこで、フォームの.Designer.csファイルを確認すると、
this.xxx.Width = ???;
という行が何故か無い。手動で追加してデバッグするも何度かするとまた消去されるの繰り返しでした。理由は不明で20個程度ある列項目の数個に発生してました。再発怖くてデザイン画面を開けないままです^^;
この類のVisual Studioのバグとか本当にどうにかして欲しいのですが、Microsoftさん、よろしくお願いします。
ラベルコントロールにコンテキストメニューを表示して入力する方法をなかなか理解出来なかったのですが、やっと実装出来ました。コンテキストメニューを表示するのはさほど難しい話では無かったです。
ContextMenuStrip contextMenuStrip = new ContextMenuStrip();
contextMenuStrip.Items.Add("◎", null, new EventHandler(lblMark_Selected));
contextMenuStrip.Items.Add("○", null, new EventHandler(lblMark_Selected));
contextMenuStrip.Items.Add("▲", null, new EventHandler(lblMark_Selected));
contextMenuStrip.Items.Add("△", null, new EventHandler(lblMark_Selected));
contextMenuStrip.Items.Add("×", null, new EventHandler(lblMark_Selected));
contextMenuStrip.Items.Add("注", null, new EventHandler(lblMark_Selected));
contextMenuStrip.Items.Add(" ", null, new EventHandler(lblMark_Selected));
として、これを表示したいラベルコントロールのContextMenuStripにセットするだけ。
lblMark.ContextMenuStrip = contextMenuStrip;
ただ、今回の場合はこのラベルコントロールを配列にしていてイベントハンドラーでどの様に処理するのかグーグル先生に確認しても明確な回答が得られなかった。まあ、そこで自力で解決するしかないのでデバッグ機能を利用しながら使えそうなプロパティを探り、ようやく実装に至った訳です。
private void lblMark_Selected(object sender, EventArgs e)
{
ToolStripMenuItem toolStripMenuItem = sender as ToolStripMenuItem;
ContextMenuStrip contextMenuStrip = (ContextMenuStrip)toolStripMenuItem.Owner;
Label label = (Label)contextMenuStrip.SourceControl;
label.Text = sender.ToString();
}
ブログにはひと月ぶりの書き込みですが、昨年末からの入退院の繰り返しもどうにか一段落したので、本業の三交代勤務でプログラミングし放題ではなくなったので、若干のスローダウンはしてますが、開発は続行中。今現在も通算何度目になるのか分からなくなってるフルセットアップ実行中。
実は先週初めからここまでのJV-Linkでのデータ読込にJVReadを使ってたのを思い切って変更してみようと着手。開発当初から少しパフォーマンスが上がると言われるJVGetsの存在は知ってたけど、メモリリークが改善出来ず、1年分取得途中でメモリ不足で止まるんだったか、まあ、対処にあまり時間取られるのも嫌だったのでJVReadで開発進めてました。で、JRA-VANの掲示板にて参考になる書き込みが有り、少しでも改善されるならとJVGetsでのデータ読込に書き換えてテストしてたりしました。
まあ、C#では自動でガーベッジコレクションされるからって事が逆に仇になってる感じで、JVGetsで取得するデータをデータベースに登録する際にゴニョゴニョしてると一向にガーベッジコレクション対象と認識されないって事の様で、この対処方法としてSafeArrayなるものを利用すればって話で、これ使ってJVGetsを採用する事が可能になりました。で、JRA-VANからデータ構造体なんかのクラス定義等が提供されているんですが、このC#版に実装されているメソッドが当初は文字列を構造体に代入する感じなのが普通に思えてたんですが、今回のSafeArrayかます関係でbyte配列を文字列にしてこのクラスメソッドにすると結局オーバーヘッドが高くなりJVReadからJVGetsへ変更るメリットが帳消しになると思ってたら、このクラス自体文字列で受けてわざわざbyte配列に最初にコピーしてるではないですか。で、このクラスをbyte配列を受けて構造体に代入するものを書き加えて後数時間で、JVGetsでのフルセットアップが終わる予定です。
JVReadでのフルセットアップには14時間17分掛かってました。本日中番出勤直前まで作業して12:19にセットアップ開始してるので、そろそろ12時間経過。もう少しで2018年まで終わりそうなので、残り3年ちょいは2時間までは掛からないだろうから多少の改善は見込めそう^^
ふと、遠い昔の記憶からデータベースでのインデックスの存在を思い出し、グーグル先生に確認しながら実装してみました。先に結果からですが、やはり画期的にスピードは上がりました。これならどうにか使えるんじゃないかと自己解決にしようかなっと。
インデックス作成はインデックスにもよりますが、当たり前ですが時間も掛かるしデータベース容量も増えるって事でメリットとデメリットがある訳で、データ登録はかなり良好なスピードなので、インデックス常駐にはしたくないかと思い、使う場所で
CREATE INDEX xxx ON table(column)
な感じで。流石に初回作成時には数十秒、1分までは行かない感じなのでギリ許容範囲かな~っと。で、使い終わる時に
DROP INDEX xxx
しておけば、データ登録に悪影響は無いかな~っと安易に考えてます。
このインデックス作成もキャッシュに乗る感じで、2回目はかなり早くなる。なので、1回目だけ少し我慢な感じです。