Skip to content

Hot-loop performance: per-record allocations in Store and RecordValidator - #4603

Open
lbwexler wants to merge 2 commits into
hot-loop-perf-2from
hot-loop-perf-3
Open

Hot-loop performance: per-record allocations in Store and RecordValidator#4603
lbwexler wants to merge 2 commits into
hot-loop-perf-2from
hot-loop-perf-3

Conversation

@lbwexler

Copy link
Copy Markdown
Member

Third batch in the stack (#4600#4602 → this) - pure internal reorg, no API or behavior changes.

  • Store.updateData / modifyRecords: summary-record membership checked against a Set of summary ids hoisted once per call. Previously a lodash {id} matcher was allocated per updated record (even when summaryRecords was null - the overwhelmingly common case), and updateData's add loop evaluated the summaryRecordIds getter - a fresh Set plus a map - once per added record (a 10k-row add allocated 10k Sets).
  • RecordValidator: record.getValues() (an object allocation over every Field) is built once per validateAsync run and threaded through evaluateRuleAsync/ruleIsActive - previously rebuilt twice per rule per field.

Validated in Toolbox: tree grid load/reload with summary row, inline-edit commit via modifyRecords + validation + revert. Zero console errors.

…rdValidator

* Store.updateData / modifyRecords: summary-record membership now checked against a Set of summary ids hoisted once per call - previously a lodash matcher was allocated per updated record (even with no summary records), and updateData's add loop evaluated the summaryRecordIds getter (a fresh Set + map) once per added record.
* RecordValidator builds record.getValues() once per validateAsync run and threads it through evaluateRuleAsync/ruleIsActive - previously the full values object was allocated twice per rule per field.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant