計算効率は作業効率に大きく影響するので，受忍限度内にファイルが開けるようになるまで処理速度を向上させるという目標でパフォーマンスの改善に取り組んでいるところだが，目下のターゲットとなっているClearTableでは，処理速度を上げることよりも，処理の透明性を確立することを主目的とする方向に転じることにする．処理の透明性は最重要課題であり，それが崩壊してカオス状態に陥る場所がCLEARTABLEフェーズであると考えられるので，この場所を完全に抑え込むことができれば，完全にクリーンなシステムという最終目標はほぼ達成されたと見てもよいはずだ．これはNODULEシステムの純度を上げ，完全に閉じたシステムとして独り立ちさせるためには不可欠の工程と考えられる．
このためには，COMMONHEADERCOMMON/SHORT/longbrPARTをきっちり整理する必要がある．手始めに共通ヘッダ定義の部分をテーブルの形にまとめてみた．NODULEクラスの仮想関数の一覧もテーブル形式にまとめた．これで大分見通しがよくなったのではないかと思う．Open Live Writer ではテーブルの編集には十分ではないので，ログインしてWordPressのエディタを使って編集するようにした．テーブルサイズがかなり大きいので持て余し気味だが，まぁ，なんとかなりそうだ．
CLEARTABLEは基本的には描画オブジェクトを初期化するというフェーズであり，基本データであるリンクデータには手を触れないというのが原則であると考えられるが，現行では系統並び替えに入る前に一度EraseTreeViewで描画オブジェクトを一度完全にパージしているはずなので，あるいは，すでにまるごと不用になっている可能性もあるのではないか？それとは逆に，画面要素を可能な限りキープして，更新された部分だけを再計算するという考え方もある．そのようなことが可能であるのか，可能でないのかも検討課題とする必要があるのではないか？
ClearTableを完全に停止してみたが，まったく問題なく動作している．ただし，前回は系統並び替えで14秒だったのが17秒と逆に増加している．これはどういうことだろう？いや，今回は復活させても17.75秒なのでやはりいくらかは早くなっている．時間が遅くなったのは，別の理由と思われる．この逆にEraseTreeViewを実行しないとどういうことになるのかを見てみよう．⇒まったく問題なく開けた．系統並び替えの時間は若干短縮して13.17秒になった．
▲ファイルを初期オープンしようとするとき，EraseFamilyTreeが重複して掛かってくる．⇒アプリ側はファイルをオープンする前にデータベースのクローズ要求を出してくる．DLL側ではファイルオープン処理の中でデータベースクローズを実行しているため．特に実害はないので，ママとしておこう．
ClearTableとEraseTreeViewの両方を止めてもまったく問題なく動作している．つまり，これらの処理はすでに不用になったと考えられる．これで，不連続点ないし不連続面が完全に払拭されたということになる．もはや最終形態に近いと言ってもよいのではないだろうか？これらの処理が入っている理由の一つとして，デバッグ時の再現性の問題がある．つまり，初期状態が完全に一致していないと，再現が困難ないし不能になる場合があり得るため，厳密に同じ状態から処理を開始する必要があるという理由だ．しかし，仮にそのような問題があり得るとしても，それはそれでまた別の方法で対処可能と考えられるので，ここでは，強引に壁を突破して前に進むことにしよう．
再現性の問題を除けば，（動作不良が発生しない限り）完全に連続した環境をキープすることに関しては何の問題もない．むしろ，そうあるべきだと言えるだろう．最後に残る問題は，系統並び替えと部分的な再描画が両立するものかどうか？という点に絞られてくるのではないか？トポロジーが変化しない限りはYリストも不変であり，座標値の再計算だけを行えばよいはずだが，トポロジーが変化したときには当然Yリストにも反映されなくてはならない．それを局所的に対処することが可能であるのなら，部分的な再描画も可能になる可能性が出てくる．
再描画の問題は局所計算の問題にも関わりがある．つまり，巨大図面の一部のみを計算して，必要になったときのみ，必要になった部分のみを再計算するという考え方だ．つまり，グーグルマップのようなことができるようになるためには，どうすればよいのか？という話なのだが…