Performance & scale

Rough guidance on graph size, computeLayout cost, and patterns for large graphs with @restormel/graph-core and @restormel/ui-graph-svelte.

There is no hard node cap in the packages — behaviour depends on device, browser, and how many DOM/SVG elements you render. Use this page as practical guidance, not a SLA.

Layout (computeLayout)

Default orbital layout walks nodes and edges to place sources and claims. Cost grows with node and edge count; for hundreds of nodes it is usually fine on modern desktops. For thousands of nodes, profile in your environment.

  • Layout runs when dimensions change and on explicit reset-layout viewport commands — not on every frame during pan/zoom.
  • If layout time dominates, pre-filter or cluster in your adapter before building GraphData.

Rendering (SVG)

  • Every node/edge can become multiple SVG elements and labels. Large graphs increase paint cost and tab-stop count — see Accessibility & input model.
  • Ghost layer doubles visual complexity when many ghost nodes/edges exist; toggle showGhostLayer off when not needed.
  • There is no built-in virtualization. For very large graphs, reduce the working set server-side or in the adapter (viewport, importance, or incremental reveal).

Recommended patterns

  1. Cap or paginate what you pass into GraphCanvas; keep “full graph” views for exports or admin tools.
  2. Use focusNodeIds / dimOutOfScope to emphasize a subset without removing data.
  3. Debounce expensive adapter work when the user scrubs filters tied to graph rebuilds.

Implementation reference: layout.ts, GraphCanvas.svelte.

← Migrate from a custom canvas · Recipes