Getting good performance for your diagrams does not require any effort on your part when the diagrams are limited to a few hundreds of nodes and links, especially on the desktop. However when your app might deal with thousands or tens of thousands of nodes and links, you may need to adapt your implementation to avoid expensive features.
The perceived performance of your diagram depends on many different factors.
Shadows are relatively expensive to draw, so consider not setting Part.isShadowed to true. Gradient Brushes are slower to draw than solid colors. Complex Shape Geometrys are slower to draw than simpler ones, and they require more computation when computing intersections.
Animation takes up resources; consider setting AnimationManager.isEnabled to false.
Keep your Nodes and Links as simple as you can make it. Limit how many GraphObjects that you use in your templates. Use simpler Panel types when feasible -- the "Table" Panel is the most featureful, but maybe you can just use a "Horizontal" or a "Vertical" or a "Spot" or an "Auto" Panel. A Panel should have two or more elements in them (although there can be exceptions). If you have no elements in a Panel, delete the panel. If you have only one element in a Panel, consider removing the panel and merging the element into the panel's containing panel.
Do not include objects that are not visible. Limit how much data binding that you use, and avoid Bindings with no source property name or that are Binding.ofObject.
If you have a Picture and you know its intended size beforehand, it's best to set its GraphObject.desiredSize (or GraphObject.width and GraphObject.height) so that it does not have to re-measured once the image loads. When nodes change size a Layout might need to be performed again, so having fixed size nodes helps reduce diagram layouts. In general, setting GraphObject.desiredSize on the elements of your nodes, especially Pictures, will speed up how quickly GoJS can measure and arrange the Panels that form your Nodes or Links.
Shapes can decrease memory usage by sharing Geometries. Shapes that are given a set size with either desiredSize or width and
height, and that are also using a Shape.figure of "Rectangle", "Circle", or "RoundedRectangle", will have their geometries potentially
shared automatically.
In other words, a single shape in a Node template defined like this:
new go.Shape("RoundedRectangle", { width: 50, height: 50 })
Will create a single geometry that is shared among all copies of the Node.
The Link.routing property value Routing.AvoidsNodes can be slow in very large graphs. Consider not using it in performance-minded large graphs, or setting it only after the initial layout is completed (use "InitialLayoutCompleted" Diagram event listener), or ideally setting it at that time only on select Links.
Using a Link.curve value of either Curve.JumpOver or Curve.JumpGap is a lot slower than not having to compute all the points where such links cross and drawing the small arc or drawing a gap.
GridLayout and TreeLayout and most other layouts are fast.
LayeredDigraphLayout is slow -- it cannot handle thousands of nodes and links. The documentation of LayeredDigraphLayout suggests some properties that you can set in order to improve performance. Contact us if you continue to have any problems.
Overviews generally require drawing a Diagram a second time, so there may be some performance impact on large graphs. Consider setting
Overview.drawsGrid to false or and Overview.updateDelay to a non-negative number.
For diagrams with many nodes and links that only display a fraction of them at a time, you could implement some form of virtualization to optimize your diagram. The Virtualized Tree sample contains 123,456 total nodes, yet is fairly quick to load and render, because it only constructs nodes and links that intersect with the viewport.
But this does complicate the implementation of the diagram, because you need to use a separate model from the Diagram.model and manage adding and removing Nodes and Links when the viewport changes. Furthermore layout is more complicated because it needs to work on LayoutVertexes and LayoutEdges, not on Nodes and Links.
Other virtualization samples are listed in the samples index.
If you want to disassociate the Diagram from the HTML Div element, set Diagram.div to null. If you remove a part of the HTML DOM containing a Div with a Diagram, you will need to set Diagram.div to null in order for the page to garbage collect the memory.
Depending on your app, it may be worthwhile to selectively toggle off some features (like shadows and animation) or to use simpler templates altogether, when slower environments are present, such as on mobile devices.
You can use multiple templates depending on your zoom level. If you are zoomed out far enough (and therefore have a lot of nodes on the screen) you can switch to a simplified template so that rendering (when panning, dragging, etc) is faster. The process of switching templates has a performance cost, though, since Parts have to rebuild themselves.
If you think you have a unique or high node count Diagramming situation that may benefit from other drawing optimizations, contact support.