椅子の上で眠り込んでベッドに戻る前に朝になった．検証テストが遅くなるという難題が発生している．フォルダやアセンブリ名の変更などでスタックサイズ変更が効いていないのではないかと思ったが，どうもそれではなさそうだ．もしスタックサイズの問題なら系列木生成の方にむしろ大きい影響が出るはずだが，特に問題はないように思われる．速度の点は比較していないので分からないが，樹高を1万以上の大きな数字にしてもスタックオーバーフローが発生しないということは，明らかにスタックの問題ではないことを示している．どうも腑に落ちないのは，検査カウント2^13の設定を3秒でクリアできる版を開発環境でリビルドするとなぜか遅くなってしまうという点だ．
つまり，おそらく昨日のどこかの時点で開発環境が変化してしまったと見るしかないような感じだ．スクロールするつもりでマウスのリールを操作すると画面に表示されているオプションリストが勝手に変化したりすることがあり得るので，どこかで不用意に環境パラメータを変更してしまっているようなことも考えられるが，VSの動作環境設定はほとんどプロジェクトが保持しているので，ここまで影響するような環境パラメータが「場」によって保持されているということはかなり考えヅライ．
どう対処したらよいのか？それが問題だ．秒速で動いているパッケージがリビルドで遅くなるとすると，問題はソースコードの問題ではないということになるから，いくらデバッグしようとしても解決を見出すことはできないだろう．まだやらなくてはならないことは山のようにあるので，このまま進むことも考えられなくもないが，いつかそれが自然解消することなど期待できないとすれば，ここでシューティングしておかないと将来禍根を残すことになる．
考えられるのは，OSの再インストールとか，別のマシンにVSをインストールしてビルドしてみるくらいのことしか思いつかない．秒速で走る版の中で最新のものは，CollatzProject 2022-02-04というものだ．その後，フォルダ名をCollatzMilkywayと変更したあとの版は全滅だ．つまり，タイミング的には開発フォルダ名をCollatzMilkywayとリネームした辺りからおかしくなってきたと思って間違いないだろう．もちろん，フォルダ名そのものの問題でないことは，CollatzProjectと呼ばれていたころの版でもリビルドして遅くなっていることから見ても間違いない．ここまでほとんどノンストップで全力疾走してきたが，思いもかけない伏兵にしてやられたという感じだ．
VS2019を修復インストールしてみたが状況は変わらない．この際なので，VS2022をインストールしたが同じだ．ビルド時にスタックサイズを変更するためのeditbin.exeの場所が違うのでエラーになったが，””C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.29.30133\bin\Hostx64\x64\editbin.exe”を指定して通った．また，VS2022はプロジェクトを開くときにネットに接続していないとエラーになる．ビルドして走らせてみたが，2^13で3分47秒もかかった．VS2019では最速で3秒，遅くとも2分以内だったのでデグレードしている．もう一つ，この環境には.NET 5.0はインストール済みなのに再インストールを求められた．
VS2019に戻すことにしてVS2019 Communityは過去バージョンのダウンロードページで探したが見つからない．マイクロソフトアカウントでサインインして中に入ったら見つかった．editbin.exeの場所も戻さなくてはならない．”C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\bin\Hostx64\x64\editbin.exe”
ようやく原因が見えてきた．少なくともこちらのソースコードの問題ではないことは確定した．つまり，最速で動いている環境にリビルドしたEXEを差し込むと最速で動作することができる．配布パッケージにはファイル（マニュアルのPDFを除く）が10本入っているが，それらのうちのどれかが速度に影響を与えているものと考えられる．これらはビルド時に生成されるので，ソースコードとまったく無関係と言えるかどうかは分からないが，プログラムの論理は基本的にすべてEXEに埋め込まれていると考えられるから，こちらの立場からすればあくまで外部（から持ち込まれた）ファイルであると言える．これらの中にはEXEが1，DLLが5，JSONが3，PDBが1含まれる．JSONはおそらく情報を保持しているだけなので，問題はおそらくこれら5つのDLLのうちのいずれかなのではないかと推定される．
原因となっているDLLはCollatzMilkyHighway.DLLという名前のDLLだ．これとまったく同じ名前のファイルがフォルダの中のrefというフォルダに隠されているが，これと置き換えるとアプリが起動しなくなる．このDLLはおそらくアプリと.NETのインタフェース用の関数群と推定されるので，アプリが変われば変化する可能性もある．ただし，これはおそらくBigIntegerの取り扱いに関わるものと推定されるので，その辺りに変更がない限りは同じものが使えるのではないかと思う．最速で動作可能なDLLをあらかじめパッケージに含むように構成できればよいのだが，このプロジェクトでは配布用パッケ時を生成するプロジェクトのようなものは存在しないので，お任せになっている．
サイズは動作する版は214KB，遅くなる版は少し小さくなって213KBだ．いや，違う．その逆だ．正確には前者が218,624バイト，後者が217,600バイトだ．デバッグフォルダにも入っているが，動作する版で217KB，遅くなる版では218KBで両者の差は約1KBだ．正確な数字で言うと，前者は222,208バイト，後者は223,232バイトで，どちらも前者と後者の差は1024バイト，デバッグ版とリリース版の差は4408バイトだ．
いつからそうなっているのかを見てみよう．バックアップは2月8日に4回，9日に2回の計6回取っているが，リリース版に限ればこの期間に3種のバージョンが発生している．①218624B，②217088B，③216576Bで今回リビルドした版は④217600Bだ．②と③ではすでに同じ症状が発生している．2022/02/08-1はソースとDLLが一致指定ない可能性もあるので，もう少し古い版をチェックしてみよう．