Performance Measurement

Performance work starts with a workload and a question. Are repeated lookups dominating runtime? Is allocation growing with input size? A single elapsed number without input size, repetitions and environment tells little.

Use performance.now for a monotonic elapsed measurement. Warm up the code, repeat comparable work, keep a checksum so the work has an observed result, and compare distributions across runs. Do not claim a tiny timing difference proves one implementation is faster on every machine.

The playground is a worker with startup and shared runtime costs. It is good for learning measurement mechanics, not publishing authoritative benchmark results. Exact durations are deliberately not part of this lesson’s predicted output. The boolean check below only establishes that a duration was recorded.

For concurrency, increasing the limit can increase memory or remote load without improving throughput. Synchronous CPU-bound callbacks still block the worker. Measure the resource and outcome that matter to users.

Predict, run, and explain

Write the output and trace the important state changes before checking it. Then run the program. Each editor is independent. Async examples end with main() so this editor waits for their work.

const started = performance.now();
let checksum = 0;

for (let n = 0; n < 10000; n++) {
  checksum += n;
}

const elapsed = performance.now() - started;

console.log(checksum);
console.log(elapsed >= 0);

49995000
true

Validate the work before comparing durations

A fast wrong result is not a useful optimization. Check an output or checksum before interpreting measured time. Keep input preparation and result consumption deliberate so two variants are compared on the same workload.

Timing varies with warmup, scheduling and the environment. Report observations rather than asserting one fixed duration in a test. If a measurement is too small to distinguish from timer resolution, repeat meaningful work locally and keep correctness checks independent of timing.

const values = [1, 2, 3, 4];
const start = performance.now();
let total = 0;

for (const value of values) {
  total += value;
}

const elapsed = performance.now() - start;

console.log(total);
console.log(Number.isFinite(elapsed) && elapsed >= 0);

10
true

The prediction checks correctness and a valid measurement shape, not an exact speed. A single four-item run is a teaching example, not a reliable performance conclusion.

const values = [1, 2, 3, 4];
let loop = 0;

for (const value of values) {
  loop += value;
}

const formula = (values.length * (values.length + 1)) / 2;

console.log(loop === formula);
console.log(loop);

true
10

The formula is valid for this special consecutive input, not arbitrary arrays. A faster special-case algorithm must state its preconditions instead of quietly changing the problem being measured.

Try the rule on new inputs

Compare several input sizes and verify results first. State the workload and environment with any timing claim. Do not make a fixed timing threshold part of the portable lesson test suite.

Your turn

// Keep the measured calculation identical to the validated calculation.

function sumTo(count) {
  let result = 0;

  for (let n = 0; n < count; n++) {
    result += n;
  }

  return result;
}

for (let n = 0; n < 3; n++) {
  sumTo(1000);
}

const started = performance.now();
const result = sumTo(1000);
const elapsed = performance.now() - started;

console.log(result);
console.log(elapsed >= 0);

499500
true

Change it and test it

Measure several input sizes locally and save the input size, repetitions and checksum with each result. Compare median timings across repeated runs. Explain why a passing elapsed>=0 check does not validate a performance claim.