今回私はTulipによる巨大グラフのインポート機能を検証する目的で、300万個のノードで構成された平面グラフを読み込ませてみた。その結果、読み込み処理が完了するまでには1分以上を要し、Tulipプロセスだけで591MBもの常駐メモリを消費する状態になったのである。このように巨大なグラフを扱う場合は、ユーザによる誤操作が重大な影響をもたらす危険性に注意しなければならない。例えば300万ノードのグラフに対してPlanar/Mixed Modelグラフレイアウトを実行させてみたところ、割り当てられていた最大3.3GBの仮想メモリをプロセスが使い尽くした果てに、途中で処理が止まってしまったことがある。なおこの試験を行ったのは、プロセスの誤判断による過剰なメモリ割り当てを防止する目的で私自身が明示的に「ulimit -S -v 3300000」による仮想メモリサイズの上限指定を施した環境であった。
私が試した限りにおいて“Import graph from Website”機能によるインポート結果は、シングルノードグラフに変換されるか、std::out_of_range例外の発生によりプログラムが中断されるかのいずれかであった。私としてはTulipの具体的な用途としてサイトの構造マップの生成を想定していただけに、この結果にははなはだ失望させられた次第である。
Tulipのホームページはポップアップ形式の広告が表示されるようになっているが、こうした広告の存在は、これからTulipを使用しようとする潜在的ユーザの一部の意欲をそぐ結果になっているかもしれない。オープンソース系プロジェクトにとってこうした広告掲載による収入は魅力的なのかもしれないが、Tulipのホームページで採用されているタイプのポップアップ広告をどの程度受け入れるべきかのバランスは、さじ加減の難しい問題である。
グラフのレイアウトを整えた上でビットマップないしベクタフォーマットへの変換処理を必要としている人間にとって、Tulipは最適なツールとして機能してくれるはずだ。Tulipを利用すればこうした変換用のコードを自力で記述する必要がないだけではなく、どうすれば自分のグラフを最も理解しやすい形態に整えられるかについても、事前に用意された各種のレイアウトを必要なだけ試すことができるのだ。またTulipへのグラフ読み込みに関しては、GraphvizのドットファイルおよびGMLフォーマットに対応したインポート機能が有用なオプションとなる場合があるだろう。いずれにせよ巨大なグラフを操作できるTulipの存在を知っておいて損はないはずだ。
Ben Martinは10年以上にわたってファイルシステムに取り組んでおり、博士課程の修了後、現在はlibferris、ファイルシステム、検索ソリューションを中心としたコンサルティング業に従事している。