Performance thinking and Big-O

Why think about growth?

Code that is instant with 100 orders can freeze with 100,000. What matters is not the time for one test run on your laptop, but how the time GROWS when the data grows. Big-O notation is a simple way to describe that growth, ignoring small details like the speed of your computer.

The most common slow pattern

A loop that calls includes, indexOf or find on another big array inside it is O(n × m). Converting the inner array to a Set or Map first makes each lookup O(1), so the whole thing becomes O(n + m).

// O(n × m): for each order, scan all blocked customers
const blocked = customers.filter((c) => c.blocked).map((c) => c.id);
const ok = orders.filter((o) => !blocked.includes(o.customerId));

// O(n + m): build a Set once, then each check is instant
const blockedSet = new Set(blocked);
const ok2 = orders.filter((o) => !blockedSet.has(o.customerId));

Measure, do not guess

console.time('dedupe');
const unique = [...new Set(bigList)];
console.timeEnd('dedupe');               // dedupe: 3.2 ms

const t0 = performance.now();            // high-resolution timer (ms with decimals)
heavyWork();
console.log(`took ${(performance.now() - t0).toFixed(1)} ms`);

Measure with realistic data sizes, run more than once (the first run includes warm-up while the engine optimises your code), and use the Performance panel in browser DevTools or node --cpu-prof to see where time really goes.

Cheap wins

• Do work once, outside loops: build Sets/Maps, compile regexes, create Intl formatters before the loop.
• Avoid repeated string building in huge loops; collect parts in an array and join once.
• Stop early: use find/some instead of filter(...)[0] or filter(...).length > 0.
• Avoid unnecessary copies of big arrays in hot loops.
• Paginate: do not load or render 50,000 rows at once.