Modeling operations become slow in large diagram

[nikku]

Describe the bug

Working on a large BPMN diagram there is a slowness when completing modeling actions, cf. large-diagram.bpmn.txt.

Steps to reproduce

1. Open large-diagram.bpmn.txt
2. Do any modeling operation
3. Perceive slowness, editor unresponsive (> 2s of wait time)

Expected behavior

• No matter how big a diagram is and what the user does, the editor remains fully responsive within reasonable boundaries (sub-second at best).
• Internal: As a developer I'm able root cause performance issues
• Fix identified levers
  • Update minimap outside of render cycle bpmn-io/diagram-js-minimap#81 (130ms)
  • Verify element template lint rule integration (130ms)
  • Consider linting improvements (130ms)
  • Consider marker updating improvements
  • Modeler is slow deselecting many elements #4335
  • deps: bump to tiny-svg@3.1.2 / min-dom@4.2.1 bpmn-io/diagram-js#910
  • deps: update to min-dom@4.2.1 / tiny-svg@3.1.2 bpmn-io/bpmn-js#2182

Environment

• OS: Linux
• Camunda Modeler Version: v5.23.0
• Execution Platform: Camunda 8
• Installed plug-ins: None

Additional context

Came up via internal feedback.

[nikku]

TODO

• Analyze where we spend most of our time
• (if needed) Expose metrics that allow us to debug such slowness

[nikku]

Analysis, executing space tool, time until editor is responsive again:

• on demo.bpmn.io: ~1 second
• on Desktop Modeler: ~3 seconds (93 errors detected)
• on Web Modeler: ~8 seconds (963 errors detected)

[nikku]

Work Log

Updated core modeling dependencies to use on board (browser) facilities for critical operations (clear, closest) - bpmn-io/diagram-js#910, bpmn-io/bpmn-js#2182.

Simplifying clear was unfortunately a failed experiment.

[nikku]

Detailed Analysis

Following up on the shallow analysis, here are some more details; using
large-diagram.bpmn.txt as a test subject in different environments.

demo.bpmn.io (stock bpmn-js)

• Snappy experience
• Make space (single frame): 480ms
  • Actual computation: 300ms
  • marker updating 70ms (remove dragging) + 60 ms (activate selection)

Desktop Modeler

Uses the minimap which adds a 30% (!) toll on rendering ➡️ bpmn-io/diagram-js-minimap#81; linting happens outside of update cycle, not the fastest, but manageable.

• Feels slightly slower
• Update total: ~700ms
• Make space (single frame): 480ms
  • Actual computation: 300ms
  • minimap updating: 140ms
  • marker updating 90 ms + 100 ms
• Lint (next frame): ~130ms

Web Modeler

Uses the minimap and many custom extensions, resulting in a massive performance blow. The diagram can barely be edited. Kapa.ai integration is responsible for more than 50% of the performance hit, linting everything three times completes the picture ➡️ https://github.com/camunda/web-modeler/issues/9606.

• Really slow
• Update total: 7s
• Make space (single frame): 4.8s
  • Actual computation: 1s
    • minimap updating: 250ms
    • marker updating: 200 ms + 200ms
  • Kapa.ai widget computation: 2.6s
  • Linting (round 1, sync): 700ms
    • elementTemplateLintRule: 130ms
    • actual linting Linter#lint: 300ms
    • storing lint results: 70ms
    • another Kapa.ai update: 143ms
• Linting (round 2, next frame): 700ms
• Linting (round 3, next frame): 700ms

[barmac]

Done. We can open individual issues.