性能调优

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.

• JavaScript code is normally several to many times slower than Java or .NET code on the same hardware platform.
• JavaScript code performance varies between different browsers and versions of browsers.
• Memory limitations, particularly on mobile devices, affect performance.
• There can be a wide variation of drawing performance on different platforms.
• Drawing and animation effects take resources.
• Complicated nodes or links are slower to build and update and draw than simple ones.
• Some layouts are inherently slower than others.

Effects and Appearances

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.

Constructing and Sizing Nodes

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 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.

Links

The Link.routing property value Link,AvoidsNodes can be slow in very large graphs. Consider not using it in performance-minded large graphs, or setting it only after the intial 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 Link,JumpOver or Link,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.

Layouts

GridLayout and TreeLayout are fast. LayeredDigraphLayout is slow.

Virtualization

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.

Other considerations

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.