巡回セールスマン問題を解く（５）

　デモ用に使っているＤＢサーバが、物凄く重たいので確認してみたら、４Ｇ積んでいるメモリを全て使い切ってスワップしまくりだった…。なんとなく、gcc の ランタイムのメモリ・アロケータは、だらしないのではないか？と思い。中途半端に終わっていた pg_allocator をまじめに実装した。札幌近辺での shortest_path だと、ノード数が増えるので時間がかかる。しかし、自分のマシンで実行すると一瞬で終了する。？？？と思ってデモ用のＤＢサーバを観察してみると、shortest_path 等の実行時にはＣＰＵが１００％で、マシンが悲鳴をあげていた…。情報化時代の戦場はウェブなんだよ。ウェブに使うマシンはケチらないで、ちゃんとしたの投資しようよorz...。と思うのだが、ウェブなんて負荷がかからないから、そこら辺の古いマシンで十分でしょという感覚で運用されてしまう。これが現実だ。
　ＴＳＰの方は、現在、異なるやり方で、１００都市ぐらいだと、一瞬で終わるようになった。まだ少し時間はかかるが、１０００都市でも解けるようになった。現在はもう完全に PostRouting という別パッケージとして独立させてしまっている。新しいアルゴリズムは、まだインプリメントしていないが、古いGA(遺伝アルゴリズム)の方は、そのうち公開するかもしれません。新しい方をブラッシュアップして、他との差別化を図っていこうかと思う。こちらまで公開して、自らコモディティ化してもしょうがない。