この勉強会に参加したかったのですが、抽選から漏れてしまったので、キャンセルして別の用を入れたのですが、気づいたら空きがあったという。
参加できず、残念だったのですが、資料を公開してくださいました。
素晴らしい。
英語ですし、基盤技術なので地味だし、難しいです。
素晴らしい発表を聞いたとしても、それを理解して実践しなければもったいない。
かなり時間をかけて資料を読みました。
でないと、発表したMaarten Balliauwはベルギー人でやっぱりビールが好きな人なんだろうなー程度でさらっと読み流してしまうので。
メモリ管理とガーベジコレクション
扱っている題材としては、.NETにおけるメモリ管理とGC（ガーベジコレクション）です。
記事を読んだ後に、GCの存在というのは、プログラミングを楽にしてくれる縁の下の力持ちではあるなと。
C++やCをやっているとわかりますが、メモリ確保と解放は、煩雑です。
私自身、これを考えずに済むという理由でC++からC#をやるようになったのでした。
おかげで開発効率は上がると。
逆を言うならば、こうしたことについて10年以上考えずにいたのでした。
メモリ割り当てについて
メモリ割り当ては、気づかないうちに起きているという。
- ボクシング
- 配列パラメータ
- ラムダ
それを気づく方法の一つが、Resharper Heap Allocation Viewer Pluginを入れる方法とのこと。
Resharper Ultimateを持っていたのですが、Resharper Ultimate Extensionは全く使ってませんでした。
では、早速、Heap Allocation Viewerをインストールすることにします。
newのようなメモリ割り当てが行われている部分に下線で明示されるようです。
GroupByは割り当てが発生するけど、Anyは発生しないと。
といっても、何かしらの処理をするのにメモリは必要となるので、無駄遣いが悪いのであって遣うことは避けられないと。
不要なメモリ割り当てを防ぐ方法
無駄なメモリ割り当てを防ぐ方法が、Object Pool パターンというデザインパターン。
すでに、オブジェクトが存在し、使われていないオブジェクトがあるのであれば、それにパラメーターを再度割り当てて使い回そうというもの。
- ガーベジコレクションはいつ実行されるかは漠然としている。それを期待せずに、メモリの省エネ運用をする。
- そもそも、ガーベジコレクションが実行されること自体、負荷となるので仕事させない。
これについてはdot Memoryの下記のドキュメントで知ってはいました。
が、言っていることはわかるけど、下手に使い回すと変な値が残ったままとなってバグの温床にならないかなーという気配もしてました。
ただ、改めて勉強してみると、身近なところでこの仕組みがあることに気づきました。
それがデータベースのコネクションプールです。
ただ、メモリやガーベジコレクションによる負荷だけでなく、データベースへのアクセスには接続の時間がかかるので、生成によるコストも抑えられる。
なるほどな、と。
ASP.NET Coreでは、そのためのArrayPoolという機構も用意されているとのこと。
この記事もなかなか読み応えがあります。
勉強することがどんどん出てきます。
