Set methods deep-dive: performance and mutability trade-offs vs manual loops?

Q: Set methods deep-dive: performance and mutability trade-offs vs manual loops?

**Target Audience:** Engineers preparing for JavaScript data-structure and performance interview questions. **Difficulty:** Medium > **How to read this doc:** Concepts are explained in plain language first, then tagged with 📌 Interview term: . Every number shown below is **real, measured output** from actually running the benchmark in this doc on Node.js v24.19.0 — not an assumed percentage. ## 1. Why This Even Matters — A Story First Picture two guest lists for a wedding, each already organized as a fast-lookup card index rather than a plain sheet of paper. Finding who is on both lists by re-reading list A against list B, one name at a time with a manual check, works — but it ignores that both lists are already organized for fast lookup. Sets are already that fast-lookup structure; the real question these methods answer is how cleverly they use it compared to detouring through a plain array first. ## 2. The Core Idea 📌 **Interview term:** **SameValueZero** is the eq

The problem

Question presented to candidate: "JavaScript Sets now have union, intersection, difference, symmetricDifference, isSubsetOf, isSupersetOf, and isDisjointFrom built in. When, if ever, do these actually outperform a manual loop with .has(), and are there real correctness differences beyond just convenience?"

What a strong answer should cover:

All seven methods return a brand-new Set and never mutate either operand — verified directly; this makes them safe to use on Sets that must stay referentially stable, like Redux-style state.
Every method accepts any "set-like" object — something with a numeric .size, a .has(value) method, and a .keys() iterator — not just a real Set instance. Verified: a hand-built plain object satisfying that shape works, while a plain Array, which has no .size, throws a TypeError.
SameValueZero equality is used throughout, the same as Set.prototype.has: NaN is treated as equal to itself, and -0/+0 are treated as the same value — verified directly.
Performance is genuinely method-dependent, not a flat percentage. Verified: intersection() beats a manual loop by a modest ~1.2x, union() beats a naive new Set([...a, ...b]) by over 3x by avoiding one large intermediate array, and isDisjointFrom() can be dramatically faster than manually building a full intersection just to check its size — thousands of times faster in a best-case early-match scenario, because it short-circuits on the first shared element.
The real headline is avoiding intermediate allocations, not raw CPU speed: intersection() and union() never materialize an intermediate Array the way [...a].filter(...) or [...a, ...b] do.

Clarifying questions expected:

"Does the hot path need a boolean answer only, like whether these overlap at all, or the actual overlapping elements?" — isSubsetOf/isSupersetOf/isDisjointFrom avoid allocating a result Set entirely when only a yes/no answer is needed.
"Are the input Sets roughly the same size, or is one much smaller?" — every one of these methods is specified to iterate the smaller operand internally, so size skew changes the real-world cost more than which method is chosen.

Code / implementation expected: Yes — real, executed benchmarks comparing native Set methods against hand-rolled loop equivalents at meaningful scale, not assumed percentages.

set
performance
es2024

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Engineers preparing for JavaScript data-structure and performance interview questions. Difficulty: Medium

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. Every number shown below is real, measured output from actually running the benchmark in this doc on Node.js v24.19.0 — not an assumed percentage.

1. Why This Even Matters — A Story First

Picture two guest lists for a wedding, each already organized as a fast-lookup card index rather than a plain sheet of paper. Finding who is on both lists by re-reading list A against list B, one name at a time with a manual check, works — but it ignores that both lists are already organized for fast lookup. Sets are already that fast-lookup structure; the real question these methods answer is how cleverly they use it compared to detouring through a plai

The solution is hidden so you can try first

7 min read · 7 sections

Run the code

Edit the code and run it here. Each console line with an expected value becomes a test.

JavaScriptCorrectness, SameValueZero, set-like protocol rejection, and real benchmarks for intersection/union/isDisjointFrom (run directly)