ＭＩＴ流なメモ

ふと、2回目のフルセットアップで出来た65GBのSQLite3のデータベースファイルに最適化してないな～っと思い、最適化するコーディングを追加。本日早速試してみるが、最初の１時間以上はなんも動きが見れず、ダメかな～っと放置。１時間半過ぎた位だったか、やっと何やら始まった感じではあるが、途方もない時間が掛かりそう。デバッグ時の単にファイルのコピーでも１０分以上必要なんで、最適化にどの程度掛かるか予想もつきませんが、今はひたすら処理してる感じです。

SSDとかだと時間の節約は出来そうですが、HDDの性能に左右されるのは間違いないかと。うちでは普通の1TB HDDでやってるので少しでも性能が良ければ時短になるのかなぁ。でも、こんなファイルをSSDに置いたらSSDの寿命は短命確定?(笑)

ちょっと様子見ようと該当ドライブ表示してたエクスプローラに切り替えたら、"応答なし"になりましたorz データ登録に掛かった14時間程度は覚悟が必要でも不思議はないかな～。

追記
3時間ちょいで完了しました。ただ、エクスプローラは固まったままw 最適化後には59GB程度にスリム(?)化されました^^

昨年の11月9日にラウンチイベントとかがあり、リアルタイムでそのイベント見たりしてたんですが、それ以前にインストールしていたPreviewが悪かったのか、インストーラーが悪かったのか...数日前に確かPreview 2.0とかのアップデートがあり、もれなくしてたんですが、その後、なんかToolなんだかがうまくロード出来ません的なエラーが出る様になり、いっその事、2019も含め、アンインストールして、更にインストーラーが２つあったんですがそれも削除。インストーラーから再度最新のダウンロードをした所、Version 17.0.4っというPreviewが付かないバージョンがインストールされました。

これはなかなかの想定外w これ、昨年のラウンチ以降にアンインストールしてからの再度インストーラーからの更新していれば、なっていたのかと思うと、ここまで何してたんだろって思うorz

まあ、何が変わっているかは未体験で、今後分かってる来るとは思いますが、悪くなってなければ良いですけどね(*^^)v

で、先日の２度目のフルセットアップは14時間程度で終わり、まあ、大体問題無い感じで、出来たDBファイルが65GB。これに更新掛ける処理のデバックに入ったんですが、テスト毎に元のファイルに戻すのに65GBのコピーはなかなか時間が掛かるorz これが作業進める気力を削ぎます。本業に復帰してるので、先日までの様に時間取れないのもあるんですが、それでも出来る限りここまで来たので進めたいです^^

ちと記憶が曖昧ではありますが、多分大晦日からこのエラーで悩んでました。基本、こちらのミスの筈なんですが、ひとりでじっとソース眺めてるとなかなか見つけられず、色んな事を疑う(笑)　テーブル名があまりにも長いからかな～っとか、NuGet不足かな～っとか、もうね、片っ端から疑って、2日掛けてようやく自分のミス見つけました。自分のコーディングを疑って何度も見て、滅茶苦茶見つめても見つからず、でもね、本当に単に自分の見落としで見つけられないミスorz これはもう、先入観なのかマジでここまで見つけられなかった理由はね～、歳で片付けていいのかな。コマンドテキストに、結局本来の項目名とは違う項目名がってのが原因だったんですが、これ、ほんの少し違う名前だったのが盲点になったんかな^^; 見つければ、何でこれ見つけるのに数日掛かるかな～っと。グーグル先生にも沢山聞いたんですが、そもそもが根本的に基本中の基本なテーブル名とコマンドテキストが不一致ってね、頑張って見つけるしかない。先入観を簡単取り除ければ近道出来るのかも。
Visual Studioで、全てのパラメーターがNullじゃない事を確認したり、まあ片っ端から確認しても、確かにこれって見つけられない。もう少し親切にテーブルにない項目が使われてますよ～っと教えてほしいorz

つい先程、2度目のフルセットアップ開始しましたので、明日明け方には終わってる予定です。前回は12月分のデータが根本的にスルーされてたので、それも含め、時間も容量も増えるかな。でも、これが最後のフルセットアップになれば満足ではある^^

明日からはもう少し本題に入れる事を願いながらしばらく実行状況チラチラ見ておきます。

開発中のDBアプリのデータ登録部がほぼ完成したので昨日初のフルセットアップに挑みました。なんと!プロセス開始から12時間51分52秒とかorz いや、実際には数日覚悟してたから逆にめっちゃ早かったんですが、これ、テストで何度もするって訳にはいかないので十分に修正箇所チェックしてやる必要がある。で、出来上がったSQLiteファイルは54GBです! ただこれ、実行中にログ見てて1年分毎に取得する様にしてたんですが、何故か期間を20200101000000-20201231235959としても毎年12月分が取得出来ないで35年分程度のデータ登録された。こちらが何処かが悪いのか提供元の問題なのか切り分けなきゃならないので、そのテストを。

今回の初施行ログがワードパットデータセーブしたんですが、124KBと別に大きいとは思えないのですが、ワードパットが悪いのかOSが悪いのか開いてサクサク動くまでに数十分掛かる。まあ、Visual Studio自体も動きが怪しい感じで...現在使っているPCは16GBしか積んでない。2年前に組む時に16GBDIMMの在庫が無いと言われ、渋々8GBで妥協したのが今になって仇になるとはorz 資金余裕があれば今なら32GB×2が3万円しないから一気に行きたいかな。

何にしても、悪い所が多いので再チェック!

Visual Studio Community 2022でのデバッグも大分慣れてきました^^
SQLiteへのデータ登録処理のログをRich Text Boxに表示してるんですが、VSC2019と微妙に動作が違う気がする。そもそも、ログ表示用で入力は受け付けないのでReadOnlyプロパティはTrueにします。で、配置サイズを超えた出力になるとスクロールバーが出るんですが、スクロールせずに追加されていき、出力内容が手動でスクロールしないと見れないのはいただけないので、これはHideSelectionプロパティをFalseにすると実現出来ます。あと、行間が広いのが気になったのでデザイン時のプロパティでは設定出来ず、FormLoadイベントで

rtbLog.LanguageOption = RichTextBoxLanguageOptions.UIFonts;

とフォント指定すると行間が普通のテキストボックスみたいというか、VSC2019時はRich Text Boxでもテキストボックスと変わらなかったのに、VSC2022では必要らしく追加する事で回避しました。

64bit化されたVisual Studioですが、VSC2019では気になった事がなかったのに、何度かデバッグで実行して中断を繰り返すとソース編集すら重い感じがするのでタスクマネージャーで確認すると、16GB積んでるメモリの13GB位まで上がって重くなっているんですが、自分のアプリがメモリリークしてるとかの原因なのか、VSC2022がプレビューでまだ動作が微妙なのかの切り分けが出来ないorz VSC2022を終了させればメモリは解放されるので、適度に再起動してます。