Performance of diagram-js for large diagrams

[Vaclav_Hala]

Hello, I have a few questions about overall architecture and performance characteristics of diagram-js. I did a quick experiment with the SpaceTool - have grid of 20 x 50 simple shapes generated, try to move about half of them by the tool - and the result surprised me. Once I activated the tool diagram-js froze the browser for about 4 seconds. After capturing performance profile of this operation:

it seems this is caused by the way diagram-js interacts with the SVG. Here’s a zoom into that profile:

in particular it seems that

• the svg operations are not batched in any way, so moving ~500 shapes causes ~500 preview ghosts to be created and appended one by one, which causes equal number of relayouts
• diagram-js not only renders into svg, but reads information back from it, which may force the browser to perform expensive computation to be able to return the information, such as performing layout to get bounding box of an element

So the questions are:

• is diagram-js simply not intended to deal with “large“ diagrams, so this sort of optimizations is not required and I’m simply using it in a way it was not designed to be used?
• or are the modules that come bundled in like PreviewSupport only an example and user is expected to provide “better“ impl of modules where needed? Given the point about reading back from svg which now that I’ve looked I can find in many places in the codebase I’m not sure how feasible that would be

Thanks

[nikku]

Good questions!

@Vaclav_Hala

• diagram-js not only renders into svg, but reads information back from it, which may force the browser to perform expensive computation to be able to return the information, such as performing layout to get bounding box of an element

Reading is cheap, unless it forces a reflow / layout thrashing. Indeed, move preview forced a reflow unintendedly - fixed via Speed up move preview setup for large selections by nikku · Pull Request #1063 · bpmn-io/diagram-js · GitHub.

@Vaclav_Hala

• the svg operations are not batched in any way, so moving ~500 shapes causes ~500 preview ghosts to be created and appended one by one, which causes equal number of relayouts

Cf. above. The issue is not creating elements, the issue was layout thrashing - forcing the browser into a forced re-layout.

@Vaclav_Hala

• is diagram-js simply not intended to deal with “large“ diagrams, so this sort of optimizations is not required and I’m simply using it in a way it was not designed to be used?

It is meant to perform reasonably for large diagrams. It is not meant to be operating at a scale of OpenstreetMap today - infinite data, truely partial rendering etc.

Best,
Nico

---

PS: Cf. Add huge-diagram performance benchmark by nikku · Pull Request #2460 · bpmn-io/bpmn-js · GitHub for a small investigation into the overall performance.