KH-FDPL に関するメモ-0002
2015.01.09
- とりあえず構造体や配列の代わりになる予定のKVSを作ってみた。これはオンメモリ仕様。
- 65536個の要素を登録して、keyから目的のオブジェクトにアクセスするまでの時間を測ってみたら、単純な配列よりも370倍も遅かった。ちなみにkeyは整数値。
- まあ柔軟性の代償だからしょうがないかー。
- いちおう単純配列型も用意するつもり。これはkeyに0～(n-1)までの整数しか使えなくて、サイズも最初に決めたものよりも大きくはできない。
2015.01.13
- こんなに遅くなるのがくやしくて少し改良したけど、全く改善しなかった。まあしょうがないかー。
- ちなみに256個の要素を登録して同じベンチマークをした場合は210倍くらい。つまりデータ件数が多いとそれなりに遅くなる。でもNが十分に大きいケースでは、O(logN)なので、基本的には筋は悪くない。
2015.01.15
- スタックマシン方式を採用して、インタプリタ部ができてきた。スタックマシンにしたのは、引数が少なくなってパースがしやすいから。それ以上の理由はない。速度とかサイズとかは一切無視。そんなものはあとでいくらでも追及できる。今はコンセプトの確認が最優先。
2015.01.16
- アクセス権を導入する予定。これにより自分がmallocしたものはfreeできるが、そうではないものについてはfreeはできない。オブジェクトにライトプロテクトも掛けられる。
- プログラムがmallocすると、アクセス権管理オブジェクトにそれが記録される。freeすれば消える。プログラムが終了するとfreeしてないもののリストとして得られる。親プログラムはこの「権利」を引き取るか、もしくは必要な結果だけを残し、残りはゴミとしてfreeしてしまってもよい。
- この仕組みによって、freeし忘れや間違ったfreeなどに対処する。
2015.01.28
- オブジェクトの管理について、リンクカウントを内部に持って、それを増減させて0になったらメモリを解放、みたいなモデルを考えていたけど、それはやめようと思う。
- 全てのオブジェクトはオブジェクトパスを必ず1つ持っていて、それはつまりオブジェクトの「実名」で、このオブジェクトパスを削除した場合は実体であるオブジェクトもメモリ解放させることにしようと思う。どれだけ他からリンクされていても、オブジェクトパスが消されたらとにかく消す。
- つまりmallocなどで確保する場合も、とにかく名前が必要になる。名前がなければそれはもはや存在できないから。でも名前を付けるのはそれなりに面倒なので、自動で名前を付ける支援機能を用意する。
- オブジェクトパスは変更できる。たとえばリンクパスのどれかをオブジェクトパスとして設定して、元のオブジェクトパスはリンクパスにするなどができる。これは権利の移譲みたいなものになる。
こめんと欄
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
