Context
Filed from investigating a real performance problem in truecalc/pro
(private, the document/undo layer built on this engine) — see
truecalc/pro#135 for the full measured evidence and root cause. Summarized
here since this is the actual engine-capability gap.
The gap
Workbook::recalc_incremental only accepts an explicit list of touched
cells and seeds its dirty closure from their direct dependents. It has no
way to express "recompute every cell whose resolution status changed as a
side effect of a structural change" — for example:
- A sheet is removed, and some formula elsewhere referenced it. That formula
should now evaluate to an unresolved-reference error, but no specific
"touched cell" list can name it — the caller doesn't know in advance which
formulas, anywhere in the workbook, referenced the removed sheet.
- A sheet is restored (e.g. via undo), and formulas that had gone
unresolved should re-resolve to real values again.
Today, any caller that needs this correctness guarantee (truecalc/pro's
undo/redo for structural edits) has no incremental option and must fall back
to a full recalc() — rebuilding the dependency graph AND evaluating every
formula cell in the workbook, even though only a small fraction of cells
actually changed resolution status. Measured cost at a 1.65M-cell/1.3M-
formula reference-model scale: 7-9 seconds for an undo that, content-wise,
only changes one sheet's presence.
What's needed
A way to ask the engine, after a structural change (sheet added/removed/
renamed), "which cells does this affect?" that is cheaper than a full
re-evaluation of every formula — likely by walking the dependency graph for
edges that resolve through a sheet-qualified reference to the changed sheet,
without needing the caller to enumerate them in advance.
Scope note
Not filed with a prescribed implementation — this needs its own design pass.
It's a change to a correctness-critical recalc path (getting this wrong
produces silently-stale unresolved-reference states, not a crash), so it
deserves careful investigation of the dependency-graph structure before
committing to an approach, in the same spirit as #983/#984's own
investigation-first process.
Context
Filed from investigating a real performance problem in
truecalc/pro(private, the document/undo layer built on this engine) — see
truecalc/pro#135 for the full measured evidence and root cause. Summarized
here since this is the actual engine-capability gap.
The gap
Workbook::recalc_incrementalonly accepts an explicit list of touchedcells and seeds its dirty closure from their direct dependents. It has no
way to express "recompute every cell whose resolution status changed as a
side effect of a structural change" — for example:
should now evaluate to an unresolved-reference error, but no specific
"touched cell" list can name it — the caller doesn't know in advance which
formulas, anywhere in the workbook, referenced the removed sheet.
unresolved should re-resolve to real values again.
Today, any caller that needs this correctness guarantee (
truecalc/pro'sundo/redo for structural edits) has no incremental option and must fall back
to a full
recalc()— rebuilding the dependency graph AND evaluating everyformula cell in the workbook, even though only a small fraction of cells
actually changed resolution status. Measured cost at a 1.65M-cell/1.3M-
formula reference-model scale: 7-9 seconds for an undo that, content-wise,
only changes one sheet's presence.
What's needed
A way to ask the engine, after a structural change (sheet added/removed/
renamed), "which cells does this affect?" that is cheaper than a full
re-evaluation of every formula — likely by walking the dependency graph for
edges that resolve through a sheet-qualified reference to the changed sheet,
without needing the caller to enumerate them in advance.
Scope note
Not filed with a prescribed implementation — this needs its own design pass.
It's a change to a correctness-critical recalc path (getting this wrong
produces silently-stale unresolved-reference states, not a crash), so it
deserves careful investigation of the dependency-graph structure before
committing to an approach, in the same spirit as #983/#984's own
investigation-first process.