You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In certain cases (specifically: large award/result notices), our platform sometimes struggles with performance. Through profiling, we’ve established that the culprit is the execution of EFX (in our case: transpiled to XPath). The time to evaluate any one expression is small, but our implementation suffers from the problem that we re-evaluate all expressions of every field after any change to the form. That is of course largely unnecessary, as the vast majority of the form will not be impacted by a single field being edited, but the reason we re-evaluate everything is because we are missing a structured way to determine which fields are related to each other.
We figure we could derive a dependency graphs between the fields from the EFX expressions to optimize our platform, but we were curious whether OP has already considered building something similar (it presumably being easier starting from the base data that is used to also generate fields.json itself and the EFX expressions, rather than reverse engineering it from them).
The way we envisage it, it could take the form of a new property "related_fields" in each field in fields.json, having an array of field ids as value (which could be empty).
With such an addition, we presume we could drastically improve the efficiency (and thereby the performance) of our form as it would lower the algorithmic complexity of our engine from linear to constant.
To put this in numbers: we recently had a notice where each user interaction would trigger ~7000 EFX/XPath evaluations. If we’d have a dependency graph, then touching any field should trigger no more than a few dozen or so evaluations (assuming the dependency graph is sparse).
Should OP not be able to provide such a dependency graph, does it seem like a good approach? Has anyone considered something similar and if so, was it a success?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
In certain cases (specifically: large award/result notices), our platform sometimes struggles with performance. Through profiling, we’ve established that the culprit is the execution of EFX (in our case: transpiled to XPath). The time to evaluate any one expression is small, but our implementation suffers from the problem that we re-evaluate all expressions of every field after any change to the form. That is of course largely unnecessary, as the vast majority of the form will not be impacted by a single field being edited, but the reason we re-evaluate everything is because we are missing a structured way to determine which fields are related to each other.
We figure we could derive a dependency graphs between the fields from the EFX expressions to optimize our platform, but we were curious whether OP has already considered building something similar (it presumably being easier starting from the base data that is used to also generate fields.json itself and the EFX expressions, rather than reverse engineering it from them).
The way we envisage it, it could take the form of a new property "related_fields" in each field in fields.json, having an array of field ids as value (which could be empty).
With such an addition, we presume we could drastically improve the efficiency (and thereby the performance) of our form as it would lower the algorithmic complexity of our engine from linear to constant.
To put this in numbers: we recently had a notice where each user interaction would trigger ~7000 EFX/XPath evaluations. If we’d have a dependency graph, then touching any field should trigger no more than a few dozen or so evaluations (assuming the dependency graph is sparse).
Should OP not be able to provide such a dependency graph, does it seem like a good approach? Has anyone considered something similar and if so, was it a success?
Beta Was this translation helpful? Give feedback.
All reactions