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
  • [ ] https://github.com/bpmn-io/diagram-js-minimap/issues/81 (130ms)
  • [ ] Verify element template lint rule integration (130ms)
  • [ ] Consider linting improvements (130ms)
  • [ ] Consider marker updating improvements
  • [x] https://github.com/camunda/camunda-modeler/issues/4335
  • [x] https://github.com/bpmn-io/diagram-js/pull/910
  • [x] https://github.com/bpmn-io/bpmn-js/pull/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) - https://github.com/bpmn-io/diagram-js/pull/910, https://github.com/bpmn-io/bpmn-js/pull/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 :arrow_right: https://github.com/bpmn-io/diagram-js-minimap/issues/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 :arrow_right: 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.