Collatz Tree Generator.exeの最新版をビルドして，サイトのownCloudにアップロードした．ownCloudはロリポップのオンライン・ストレージ・サービス（追加費用なし）だが，これまで使ったことがなかった．中にフォルダを作ったり，パスワードを設定したりなどのことができるので，利用できそうだ．
物理数学etcグループのコメントで公開したことを告知したが，早速エラーが出てしまった．枝数3，樹高19の設定で以下のパネルが出る．
メモリ不足が起きているが，このあと次のパネルが繰り返し出てくるようになる．
エラーハンドラにResume Nextの（デバッグ用の）行が残っていたためだ．メモリ不足が発生するのは避けられないので，エラーが発生したときには処理を中断することしかできない．⇒このエラーはサブノートで発生しているが，メイン機では同じ設定で走っている．サブノートのRAMは4GBしかないが，メイン機には32GBまで実装されている．しかし，28.9GBまで使っているので実際の動作はほとんど停止しているのに等しい．相当のインターバルでほんのわずかしか進んでいない
配列サイズの計算が過小でオーバーフローしている可能性はないだろうか？⇒確認しておいた方がよい．⇒メイン機の動作がおかしい．スタートメニュー→設定→システムでパネルが開かない．アプリを閉じても同じ状態が続いている．一度再起動するしかなさそうだ．．⇒消費メモリが28.9GBとなっているので，32GB実装と思ったが，システム→詳細情報で見ると，16GBしかない．ということは仮想記憶を使っているのだろうか？だとすればムチャ遅いというのも分かる．もしかすると，メモリを過剰に消費している可能性もある．Cドライブの空領域はアイドリング状態で30GBだ．デスクトップで60GB使っているので，これをどこかに移せばもう少しリラックスするのではないか？
Dドライブは13GBしか空いていないが，Eドライブには194GBの空きがある．デスクトップ上のファイルを一度すべてEドライブに移してしまおう．対処策の一つとして，ノード番号配列をQueにしてしまうという手がある．満杯になったらスタートに戻って反復使うという発想だ．書き込みが読み出しを追い越してしまうということは起こり得るだろうか？少なくとも最上階の1段分が格納できれば不足することはないと考えられるが…実装は多少厄介なので，もう少し現状で使うことにしよう．⇒Cドライブの空き領域が91.5GBになったが，樹高9辺りでガクンと遅くなる状態には変わりがない．確かに少しだけ速くなったような気はするが…
ノード配列サイズは1743392220で有効ノード数が1664738610の辺りから遅くなってくるが，まだオーバーフローはしていない．階数が10の辺りでは一度に75点程度しか処理されない．そのたびに長いインターバルが入る．実装メモリが16GBしかないとすると，それ以上の部分はすべて仮想記憶でまかなっていることになるので，スラッシングが発生しているのではないだろうか？3^13=1162261467で予約された配列サイズの1743392220よりは小さい．最上階のノード数が確保できれば何とか動作するのではないだろうか？もちろんQueの構造にした場合だが…
サンプルサイズを樹高18に設定すると，所要配列サイズは581130752，所要メモリは12GBくらいで楽勝に走っている．ただし，消費メモリはしだいに増加しているので，最後まで持つかどうかは分からない．⇒メモリ14.7GBくらいからポーズが入ってくるようになる．確かにGCが頻繁に発生するようになっているので，それが遅延の原因だろう．確かに，現在の配列サイズ決定論理はあまりできがよくない．最大でも581130733しかないのに，それより大きい581130752という数字を使っている…3^18=387420489なので，D^Hの方がだいぶ小さい．有効ノード数はそれよりはるかに小さいので，とりあえず，D^Hサイズをリザーブするようにしてみよう．
かなり快調に走るようになってきた．それでも階高12でメモリ13GBを超えた辺りから息切れし始める．D^(H-1)でも十分間に合いそうだ．⇒D^(H-3)+D^3に書き換えてみたが，なかなか12階を超えるのは難しそうだ．すでにメモリを14.5GBまで使い切っている．⇒有効ノード数というのは完全正則木のノード数と比較するとかなり小さいので，この数字を正確に計算できればかなり楽になるのではないかと思う．モヒティがこの計算式を書いてくれることになっているのだが，そもそも彼はPCすら持っていない！ので当てにすることはできない…ようやく13階まで回ってきたが，18階にまで達するのは容易ではない．この件は保留ということにして，進むことにしよう．
と言っても，このアルゴリズムの妥当性はチェックしておく必要がある．特に樹高の低い木で問題が起こる可能性がある．動的に配列サイズを変更しておくというのも一つのやり方かもしれないが…とりあえず，最低限配列サイズオーバーだけは見ておくことにしよう．課題としては以下がある．①ノード配列を（固定サイズの）Queに変える，②配列サイズを動的に増加させる，③配列サイズの予測計算式を立てる．
現在の計算式では動作しない．次のように変えてみた．M=D^H/3 + D^3 ⇒これなら何とかいけそうだ．⇒メモリの使い方が変わってしまったのだろうか？前はGBオーダーで走っていたのに，150MBという水準で推移している．ただし，GCがひっきりなしに発生している…D=12までは難なくこなせた．D=13もすでに最後の段を出力するだけになっているので，妥当な時間内に完了するだろう．⇒終わった．58分19秒掛かった．重要な点に気が付いた．3の倍数ノードの個数は正確に有効ノード数の1/3になっている．いまの場合，有効ノード数は24574で3の倍数ノードは8191だ．