Skip to content

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

Description

@ljodea

Context

Found while reviewing runtime/SSR complexity in packages/svelte/src alongside #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.pushexclude.add)

Acceptance sketch

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions