sveltejs / svelte · Issue No. 18601

perf: use Set for rest-prop exclude lists (server, legacy, exclude_from_object)

Openby ljodeaopened Jul 29, 2026updated Jul 29, 20260 comments

Description

Context

Found while reviewing runtime/SSR complexity in packages/svelte/src alongside https://github.com/sveltejs/svelte/pull/18602.

Problem

Modern client rest_props already takes a Set of excluded keys and uses .has. Several sibling paths still use arrays + .includes:

Path	File	Complexity
Server `rest_props`	`packages/svelte/src/internal/server/index.js:349-358`	O(\|props\| × \|rest\|) per SSR of a rest-props component
`exclude_from_object`	`packages/svelte/src/internal/shared/utils.js:127-143`	O(\|obj\| × \|keys\|) for rest destructuring
`legacy_rest_props`	`packages/svelte/src/internal/client/reactivity/props.js:101-157`	O(\|exclude\|) per get/has/ownKeys on `$$restProps`

What n represents: Number of incoming prop keys × number of named excluded props. Exclude lists are compile-time fixed but prop bags can grow; SSR multiplies across requests.

Why not in #18602

Client runes path already uses Set. Remaining work spans SSR + shared utils + legacy mode and needs coordinated compiler emit changes (pass new Set([...]) or accept array|Set). Separate from the $: Map fix.

Suggested direction

Prefer Set (or dual accept Set/array) for exclude lists
Align server transform emit with client runes (new Set(...))
Keep deletion semantics on legacy_rest_props (exclude.push → exclude.add)

Acceptance sketch

Same rest-prop contents client/SSR/legacy
Membership O(1) for exclude checks
No regression on rest destructuring / $$restProps samples

Relay Analysis

View on GitHub

Relay reads this issue against the repository's contribution signals: the files it is likely to touch, how the maintainers triage work this size, and what the first contribution would exercise.

The full analysis for this issue is still being assembled. Until then, the description above and the thread on GitHub are the most reliable context.