[Perf] : Split dataTree for eval

[ApekshaBhosale]

Is there an existing issue for this?

• [X] I have searched the existing issues

SubTasks

As we know we have a dataTree which holds all properties and evaluated values. As part of the performance improvement we can make split this dataTree into dataTree and entityConfig -

1. DataTree - which has evaluated values and paths which actually needs evaluations
2. entityConfig - this will have all config properties which are needed for like dependency map ie DynamicBindingPathList, DynamicPaths, TriggerPaths, ValidationPath, etc.

Benefits -

1. During update dataTree, will take difference between oldDataTree and dataTree avoiding all the path which doesn't neeed evalutions
2. size of dataTree will be reduced which will help during evaluations

[ashit-rath]

Right now when we try to bind any entity, the whole entity object in the data tree gets returned as the evaluated value. It contains a ton of properties that is not relevant to the end-user, so are we considering fixing this as well when we are talking about splitting?

[rishabhrathod01]

@ashit-rath Though we don't aim to fix this particular problem with the above change. But removing those paths from the data tree will actually also fix the issue you mentioned. for example, trigger path, validationPaths, bindingPaths, and so on.

[ApekshaBhosale]

https://github.com/appsmithorg/appsmith/issues/13982 will be solved as part of this

[rishabhrathod01]

https://github.com/appsmithorg/appsmith/issues/13982 will be solved as part of this

Makes sense.

[rishabhrathod01]

Oops sorry, I closed the wrong issue.

[somangshu]

@Rishabh-Rathod why is this assigned to @ApekshaBhosale ? What is pending here?

[rishabhrathod01]

@somangshu We shipped all the performance improvements planned with the dataTree split using a different solution (prototype-based). That way we were able to ship performance faster.

The prototype-based solution was an ad-hoc idea that came when we picked dataTree split and also back then priority was to improve performance as soon as possible. We shouldn't have closed the dataTree split task ideally back then.

Hence, now we re-open it, and completing this would now give us architectural benefits. ( performance gains were mostly achieved by the prototype-based solution )