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.
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
!importantflag in a CSS spreadsheet.
Ogma.styles.setThemeAPI to define your default styles.
Do not call
setAttributeson elements before they are added. Wait for
setGraphpromises to resolve before.
Prefer setting styles to
EdgeListdirectly rather than iterating on a
Listto set attributes to each element.
// slow ogma.getNodes().forEach(node => node.setAttribute(...)) //fast ogma.getNodes().setAttribute(...)
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
- 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
Reactand 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
autoStopoption to stop the layout when it is stable enough. Otherwise, you can set the amount of steps manually with
gpuversion 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
forloop, you are probably doing something wrong.
- check the dependencied between your styles. You can read more in the style rules optimization tutorial.