Skip to content
  1. Tutorials

Best practices and performance

Ogma provides a large API with optimized functions, but some missuage of some features can lead to a slow app, or hard to maintian. This tutorial aims to present best pratices when using Ogma.

Best practices

First steps

  • Use one graph.addNodes() instead of multiple graph.addNode() (same for edges), as well as graph.removeNodes() instead of multiple graph.removeNode().
  • Text is really expensive in term of graphics memory. For reference, one character uses as much space as a node shape. Consider disabling texts if you run out of graphics memory.

Styling

To style your vizualisation efficiently and easily, there are few simple rules you should follow:

  • See StyleRules as a CSS spreadsheet. Do not re-create classes and styleRules over time, but once for all.

  • Avoid setting attributes directly into elements, as it overrides every classes and styleRules. See setting attributes as an !important flag in a CSS spreadsheet.

  • Use Ogma.styles.setTheme API to define your default styles.

  • Do not call setAttributes on elements before they are added. Wait for addNodes, setGraph promises to resolve before.

  • Prefer setting styles to NodeList and EdgeList directly rather than iterating on a List to set attributes to each element.

js
// slow
ogma.getNodes().forEach(node => node.setAttribute(...))

//fast
ogma.getNodes().setAttribute(...)

Performance

All performance issues that you may encounter with Ogma, can be put into following categories:

  • Data transfer: loading data from the server to the client, it is actually out of Ogma's control, but we will give you some tips to optimize it.
  • Layout: computing the position of nodes and edges, this is the most time consuming part of the vizualisation. There are tricks to optimize it depending on the nature of your data.
  • Rendering: drawing the graph on the screen, this is the second most time consuming part of the vizualisation. Although Ogma's WebGL renderer is optimized, there are still some things you can do to improve the rendering time.

Optimizing the loading time

Ogma can load and render huge graphs, but this is not a reason to abuse the final user's patience and attention. Here are a few recommandations to keep your app at speed:

  • Filter your graph on the back end. For development purposes you can load huge graphs and filter it afterwards but in production you should render only necesary nodes and load new elements dynamically.
  • Keep your styles neat. As said above, you should keep the number of styleRules low, and avoid non-linear computations within styleRules.
  • Preprocess your data. Nodes and Edges can hold a lots of data on your database, but not all of it is necessary for your app. If you are using frameworks like React and are including the whole graph in the state of the app, data changes can become really heavy.
  • When using frameworks, follow the recomandations written in our dedicated tutorials:
  • Consider using clustering API if you group nodes but rarelly ungroup them.

Optimizing the layout time

Layout is the most time consuming part of the vizualisation. It is also the most important part, as it is the one that makes your graph readable. Here are a few tips to keep your layout fast:

  • Use the right layout settings according to the dataset size. For example, on a graph of more than 1000 nodes you really don't care about some nodes overlapping each other, so you can switch that part of the calculation off with elasticity: false
  • Use autoStop option to stop the layout when it is stable enough. Otherwise, you can set the amount of steps manually with steps option.
  • Use gpu version of the layout if you can. It is faster than the CPU version, but it is not available for the graphs bigger than 7000 nodes.

Optimizing the rendering time

We have dedicated several tutorials to this topic, so we will not go into details here. Here are the main points:

  • Make sure your style rules are not doing heavy and unnecessary computations. If something can be computed once - cache it.
  • There's an easy rule to assess the complexity of the code in the style rules: If you have a double for loop, you are probably doing something wrong.
  • check the dependencied between your styles. You can read more in the style rules optimization tutorial.