Overview
After commit, the user must re-enter edit mode to assign a second field. On large meshes this pays full session-begin overhead every time: export_active_dataset_for_editing (Fetch + possible temp write), begin() (DeepCopy), and set_edit_target_dataset (B5/B5b cache builds). For multi-field workflows this compounds per assignment.
Options
Option A — revert to pre-PR-#37 architecture
Before PR #37 there was no edit node; working_dataset was a DeepCopy of Fetch(source) and picking ran against the original source proxy. After commit the source proxy still pointed at the original file; re-entering just re-fetched and re-copied — identical session-begin cost to today. Reverting also brings back B3 and B4 (per-pick Fetch + coordinate-map rebuild on every interaction), which were the primary motivation for PR #37. Not viable.
Option B — persistent edit node across commits
After commit: write working_dataset to disk, load the result as a new pipeline node, then swap the edit Reader to point at the new committed file — keeping _edit_source_point_indexes, _edit_boundary_elements, and the EditSession geometry caches alive.
- Valid when only field values changed (no
materialize_surface_selection): topology is identical, all caches hold.
- Invalid after materialization: new codim-1 cells inserted, caches must be rebuilt anyway.
Requires changes to the commit lifecycle in paraview_backend.py and tracking whether materialization occurred.
Option C — lazy cache builds (smallest fix)
Build _edit_source_point_indexes and _edit_boundary_elements on the first surface pick rather than eagerly at session begin. Session begin is fast again; the first surface pick after re-entry pays the same cost (identical total, different distribution). Orthogonal to B and trivial to implement — already noted in issue #34 comments as a mitigation for the B4 eager-build trade-off.
Recommendation
Option C is the smallest-effort mitigation and applies regardless of whether B is also pursued. Option B is the correct long-term fix for multi-field workflows.
Related
Overview
After commit, the user must re-enter edit mode to assign a second field. On large meshes this pays full session-begin overhead every time:
export_active_dataset_for_editing(Fetch + possible temp write),begin()(DeepCopy), andset_edit_target_dataset(B5/B5b cache builds). For multi-field workflows this compounds per assignment.Options
Option A — revert to pre-PR-#37 architecture
Before PR #37 there was no edit node;
working_datasetwas a DeepCopy ofFetch(source)and picking ran against the original source proxy. After commit the source proxy still pointed at the original file; re-entering just re-fetched and re-copied — identical session-begin cost to today. Reverting also brings back B3 and B4 (per-pick Fetch + coordinate-map rebuild on every interaction), which were the primary motivation for PR #37. Not viable.Option B — persistent edit node across commits
After commit: write
working_datasetto disk, load the result as a new pipeline node, then swap the edit Reader to point at the new committed file — keeping_edit_source_point_indexes,_edit_boundary_elements, and theEditSessiongeometry caches alive.materialize_surface_selection): topology is identical, all caches hold.Requires changes to the commit lifecycle in
paraview_backend.pyand tracking whether materialization occurred.Option C — lazy cache builds (smallest fix)
Build
_edit_source_point_indexesand_edit_boundary_elementson the first surface pick rather than eagerly at session begin. Session begin is fast again; the first surface pick after re-entry pays the same cost (identical total, different distribution). Orthogonal to B and trivial to implement — already noted in issue #34 comments as a mitigation for the B4 eager-build trade-off.Recommendation
Option C is the smallest-effort mitigation and applies regardless of whether B is also pursued. Option B is the correct long-term fix for multi-field workflows.
Related