- SpiderMonkeyエンジンの JavaScript・WebAssembly コンパイル過程を可視化するため、内部ツールを全面刷新し、インタラクティブグラフを生成する機能を実装
- 既存の Graphviz ベースの iongraph はレイアウトが不安定で構造も直感的ではなく、デバッグ効率が低かったため、これを置き換える 新しいレイアウトアルゴリズム を独自設計
- 新アルゴリズムは Sugiyama 方式を単純化し、ループ構造を明確に表現しつつ、安定・高速なレイアウトを 1000 行未満の JavaScript コードで実装
- グラフは 鉄道路線図スタイルの直線エッジ を用いて可読性を高め、Graphviz と比べて数千倍高速なレンダリング速度を達成
- このツールは Firefox Profiler に統合されており、今後は 検索・レジスタ可視化機能 などへの拡張計画がある
SpiderMonkeyの可視化ツール刷新
- SpiderMonkey の Ion 最適化コンパイラ が生成する内部グラフを可視化するため、ツールを新たに構築
- ユーザーは Web ページ上で JavaScript コードを入力し、関数最適化の過程をリアルタイムのグラフで探索できる
- グラフはドラッグ・ズーム・スライダー操作により、段階ごとの変化を確認できる
- 既存の Graphviz ベースの iongraph は PDF 出力を生成していたが、ソースコード構造と一致せず、出力の不安定さも深刻だった
- 小さなコード変更でもノード位置が大きく変わり、パス間の比較が難しい
- ループや条件文の構造が視覚的に歪められ、制御フローの把握が難しい
Graphvizの限界と新しいアプローチ
- Graphviz の Sugiyama アルゴリズム は一般的なグラフ最適化には適しているが、制御フローグラフ（CFG） の特性を反映できない
- JavaScript・WebAssembly のループは単一の入口しか持たず、簡約可能な（reducible）制御フロー を持つ
- SpiderMonkey チームはこうした制約を活用し、単純化した専用アルゴリズム を設計
- サイクル除去: ループのバックエッジを無視
- 階層化（Leveling）: ループ後のブロックを下に配置し、コードの流れを反映
- 交差最小化を省略: 安定性を優先し、true/false 分岐の順序を固定
- ループ木構造の保持: ネストしたループを視覚的に明確化
- その結果、簡潔・高速・安定したレイアウト を実現し、初期実装は約 1000 行の JavaScript で構成された
iongraph レイアウトアルゴリズムの段階
- 1段階: Layering
- ブロックを階層ごとに整列し、ループ内外の関係を反映
- ループ終了後のブロックは、ループ全体の高さぶんだけ下に配置
- 2段階: ダミーノード生成
- 複数階層をまたぐエッジにダミーノードを追加し、視覚的な衝突を防止
- 同じ目的地へ向かうエッジは統合して 視覚ノイズを低減
- 3段階: エッジ整列（Straighten）
- 親ノードと子ノードを揃えて 垂直線の形を維持し、ループのインデントを適用
- ダミーノードも整列処理に参加し、重なり防止と構造保持 に寄与
- 4段階: 水平エッジトラッキング
- 水平エッジが重ならないよう トラック（track） 単位で整列
- エッジ方向に応じて上下に分離し、統合可能なエッジはひとつにまとめる
- 5段階: 垂直配置（Verticalize）
- 各階層に Y 座標を割り当て、均一な高さで配置して可読性を向上
- 6段階: レンダリング（Render）
- 鉄道路線図スタイルの直線エッジを使用
- エッジは垂直・水平にのみ交差し、方向性と構造が明確
単純なアルゴリズムの効果
- 複雑な最適化の代わりに、予測可能なルールベース配置 により 可読性と安定性 を確保
- ノード順序の固定、エッジ単純化により パス間の一貫性を維持
- 制約ソルバー（Constraint Solver） を排除することで、人間が理解しやすい構造 を実現
- ループ内部の配置や後続ブロックの下方配置など、意味中心の設計 が可能
- 性能向上: Graphviz では 10 分かかっていた zlib 関数グラフを 20 ミリ秒 でレンダリング
今後の計画
- Firefox Profiler への iongraph 統合は完了しており、性能分析時にグラフを確認可能
- 現時点では SpiderMonkey シェルビルドでのみ利用可能で、ブラウザビルドには未同梱
- 今後の機能提案
- 高度なナビゲーション機能、検索、レジスタ割り当ての可視化 など
- 明確なロードマップはなく、オープンソース貢献 を歓迎
- ローカルで試すには
IONFLAGS=logs を設定して /tmp/ion.json を生成し、
スタンドアロン版で読み込み可能
- ソースコードは GitHub で公開されており、
Matrix チャットルーム を通じて開発者と直接やり取りできる
1件のコメント
Hacker Newsのコメント
正確に比較するなら、Graphviz全体ではなく dot(1) との比較になる
Graphvizは複数の レイアウトエンジン（dot、neato、fdp、sfdp、circo、twopi など）を含む可視化フレームワーク
新しく提案されたアルゴリズムがGraphvizに貢献されるなら、本当にすばらしいと思う
関連ドキュメントは Graphviz言語説明 と dotレイアウトエンジン文書 を参照
制御フローグラフ（CFG）のうち reducible control flow を持つ場合にはうまく動くかもしれないが、複雑な例外が多そうだ
そのうえiongraphは JavaScriptベース なので、Graphvizに統合するには ClaudeのようなツールでCに変換 する必要がある
アルゴリズムの 原実装を自分で読み解く力 は本当にスーパーパワーだと思う
Graphvizで複雑な可視化をしたことがある立場からすると、誰かが直接再実装したと聞いて最初は驚いた
でもアルゴリズムの構造を見ると、思ったより単純なのかもしれないという気づきがあった
ただ、実際に実装を終えるまでは 隠れた複雑さ が分かりにくい点は変わらない
汎用アルゴリズムを特定の問題領域に特化 すると、ずっとよい結果を得られることがある
ただ、たいていの場合は利便性のために汎用アルゴリズムをそのまま使っている
特定アプリケーション向けに合わせたシステム設計は、性能・拡張性・耐障害性 のすべてで大きな改善をもたらす
ただし1000倍の改善を狙っていると、1〜2年などあっという間に過ぎる
汎用グラフレイアウトシステムははるかに多様なケースを扱わなければならないので、複雑にならざるを得ない
だから入力を分析して、特殊ケースでは高速なアルゴリズムを使い、それ以外では 保証された汎用アルゴリズム を使う折衷案がよいと思う
いい記事だった。参考までに言うと、Graphvizのdotは Sugiyamaアルゴリズムの純粋実装 ではない
実際の実装は サイトの論文 に詳しく書かれている
大きなグラフでdotとiongraphを比較した画像を見ると、dotは 面積最小化 に最適化されていて、iongraphはそうではない
大規模グラフの可視化は見た目は魅力的だが、実際には 役に立つことが少ない
可視化が有効なのは数十ノード程度までで、それを超えると エッジの複雑さ のせいで理解しづらくなる
結局、単純な例ではうまく機能しても、複雑な環境ではむしろ邪魔になる
ほとんどの問題は小さな単位に縮約できる
ただGraphvizは小さなグラフでも 見た目がいまひとつ で、iongraphは 線の可読性 がずっと高い
長期的には 検索、強調表示/非表示機能 のようなインタラクティブ要素が必要だと思う
ダイアグラムが リンクを出したり受け取ったりできない制約 がもどかしい
Mermaidもテキストリンクは可能だが、ダイアグラムリンクは制限が多い
StackOverflowの関連議論 も参考になる
こうした機能が 設計段階から第一級機能として考慮されたツール が必要だ
Graphvizの本当の強みは dot言語 にある
dotで定義されたグラフは 複数ツール間の互換性 が高く、文法も単純で読みやすい
Mermaidのような代替が登場したが、dotは依然として 標準フォーマット として長く残りそうだ
本当にすばらしい記事だった
こうした技法がD2の TALAレイアウトエンジン にも使われているのか気になる
TALAの例を見る
グラフ描画に興味があるなら Will Evansの講義（リンク）をおすすめする
私は以前、Open Graph Drawing Framework（OGDF） のDot lexerにバグ修正をコントリビュートしたことがあるが、
OGDFはGraphvizより 交差が少なく高速なアルゴリズム を実装している
私の経験では、OGDFの結果の方がずっときれいだった
関連するPR履歴は GitHubリンク を参照
興味深い。サンプルは どう実行するのか 気になる
このプロジェクトのよい点は、Webクライアント環境を前提にしたインタラクティブな探索支援 だ
制御フローグラフ（CFG）に特化したレイアウトなので、ドメイン特化の可視化 が可能になる
Graphvizにも ポリライン、エッジ順序制御 の機能はあるが、ドキュメントが不十分だ
BrandesとKopfの エッジルーティングアルゴリズム を統合できるとよさそうだ
Graphvizは40年近い歴史のあるプロジェクトで、現在は第二世代のボランティア数名が保守している
ツール作りは常に難しい市場で、ユーザーは賢いが 予算の少ない部門 に属している
宣言的2Dダイアグラムツールの進化が遅い現実 は残念だ
こういう分野で働く人にはいつでも +1で応援 したい
私も mermaidとgraphviz を使ったことがあるが、結局 FigJam に戻る。可読性と美的完成度が高いからだ
graphvizは 巨大なバイナリ、mermaidは ブラウザのSVGレンダリング 依存で扱いづらい
単に テキストでダイアグラムを簡単に作れるツール が必要だ
著者が示したアプローチは、この トレードオフを制御 しようとするよい試みだと思う
ループを処理していない点を除けば満足だった
SVG/HTML出力 はスタイル変更やコピーに有利だ
テキストベースのダイアグラムツールが欲しいなら TikZ をおすすめする
TikZのWiki を参照
ただしFigJamのような 即時の視覚フィードバック はない
mermaidの 依存関係の多さとコードの一貫性のなさ が気に入らなかった
一方で nomnoml（リンク）はコードがきれいで、TypeScriptに移植された graphre（リンク）もある
mermaidをresvg-jsと一緒に使うには、SVGテキスト幅測定 に関するリファクタリングが必要だ