Node Tool or Dynamic Offset LPE: Where Should a Revisable Outline Live?

The short answer

If the source path is still evolving, the outline should live in a Dynamic Offset LPE, not in a hand-edited duplicate. The crossover point is not a node count — it is roughly the second revision. A duplicated, node-edited border costs you one re-trace per source change; an LPE costs you nothing per change until you flatten it. Only switch to manual node editing when rendering cost or file portability forces the issue, and even then, flatten a copy of the LPE rather than re-tracing from scratch.

Why the LPE wins on revision count

Dynamic Offset keeps the source path's d attribute untouched in the XML and stores the outline as a single offset parameter hanging off an effect reference. Every edit to the source — dragging nodes, reshaping handles, extending the path — flows through to the border automatically. A node-edited duplicate inherits nothing: the moment you move the source, the border is wrong, and the fix is destructive manual work each time. So the break-even is not "after a few revisions" in any measured sense; it is the first revision after the border was drawn. The only scenario where the duplicate is genuinely cheaper is the truly finished, one-off drawing — which is the case you already excluded.

Linked Offset and restructuring fragility

Linked Offset tracks the source through its XML identifier, so adding or deleting individual nodes on the source path generally updates the offset cleanly. What it does not survive well is identity-level restructuring: operations that delete the path element and recreate it (some boolean operations, certain paste-in-place workflows, or replace-style edits) can mint a new ID or orphan the reference, leaving the offset frozen on cached geometry or gone entirely. This is the same class of fragility clones exhibit, and it is worth flagging as a likely explanation rather than a guaranteed behavior — exact failure modes vary by operation and Inkscape version.

The practical safeguard is cheap: after any structural operation on the source, open the XML editor (Shift+Ctrl+X) and confirm the target path still carries its effect reference, then nudge the offset parameter and watch the preview update. If it does not, re-link before doing more work.

The performance threshold question

There is no documented node-count or chain-length threshold where LPEs become unsafe, and any specific number would be misleading — rendering cost depends on your CPU/GPU, Inkscape version, total document complexity, and how many effects are stacked on the same path. What is well established is the direction: each active LPE adds per-render recomputation, and dense source paths multiply that cost, so long LPE chains on complex documents are a common source of sluggish canvas redraw and slow export.

Instead of trusting a threshold, measure your own file once:

1. Duplicate the document. In one copy, keep the Dynamic Offset live; in the other, flatten it (Path > Object to Path on the offset, after duplicating the effect if you want to keep a parametric original).
2. Time a consistent operation in both — a full-canvas zoom redraw or an export to PNG at production resolution.
3. If the difference is invisible, keep the LPE. If the live version is noticeably slower, ship the flattened copy and archive the parametric one as the editing master.

One hard rule regardless of choice

Flattening is one-way. Once an LPE is converted to plain path data, the parametric control is permanently gone, and the next source revision means re-applying the effect or hand-editing — exactly the re-tracing cost you were avoiding. Treat the LPE version as the master and any flattened output as a derived artifact, the same way you would treat source and build output.

Note: performance claims here are directional, not benchmarked. If your decision hinges on a specific slowdown, the two-copy timing test above is the reliable arbiter for your hardware and document.