Improve form performance (tracking issue)

[Skaiir]

What should we do?

We should conduct an optimization pass for fjs, as there are some performance issues reported when dealing with large forms.

Why should we do it?

To keep the modeling experience as fluid as possible.

Sample form available here.

Potential improvements

To research

• [ ] can we improve the evaluation time of FEEL ?
• [ ] can we efficiently cache the result of FEEL evaluation, and if so, would performance improve ?
• [ ] can we reduce the overall number of re-renders by using signals ?

To implement

• [x] minimize the number of recalculations of the feel data context (shipped via #808)
• [x] https://github.com/bpmn-io/form-js/issues/958

[Skaiir]

Internal: started a chat with modeler team [here]

[barmac]

I checked the form you shared and indeed it hangs the form playground for a while. Still, the regex looks OK, and a single evaluation does not take that much time on my machine. So it's more a "death by a thousand paper cuts", i.e. that particular function is executed too often. Note that the normalizeContextKey function is called within the context of conditional fields. Perhaps we could save some executions if we confirm that the condition mechanism is causing the problem.

[Skaiir]

This is still ongoing.

This issue here was raised regarding performance in tasklist for big forms. https://github.com/camunda/tasklist/issues/3758

Following investigations, the performance issues are due to the following:

• feel evaluations are a bit slow, as mentioned above there have been some investigations into feel noticing nothing specific, but I still think something's going on there, nevertheless we can leave that for later
• we were overly recalculating filtered state by having the computation within a hook, as part of dynamic list, we're moving this to a context which should reduce calls to feel and make our life easier. This has already improved performance significantly but not to the level that we would like long term
• we are not caching expressions in any way, so we need to recalculate them all every time the state changes, which could be one avenue where we could make improvements to the performance
• finally, we could only recalculate the feel expressions whenever the specifically mentioned state objects are updated. This requires us to leverege getSchemaVariables (or a smaller version of it). Might be a bit complex and bug prone, but it would make our life a lot easier
• or alternatively to that, we could have smarter state management. Using one monolithic object for state has plenty of issues, there are quite a few mechanisms we could put in place to fix that, generally this would be a large refactor but it would bring some improvements beyond just feel across the entire application

[marcosgvieira]

@Skaiir as we released improvements for the performance on form-js in our latest release, should we close this one or is there something else we plan to execute?

[Skaiir]

@marcosgvieira I will unassign myself but keep this issue open in the backlog for future improvements. We need to wait on feedback but generally there are still things that could be improved :D