Optimization and deoptimization

JavaScript is dynamic: the same function can receive numbers, strings, or objects with different properties. An engine must preserve that behavior, but it may generate faster code when runtime observations stay predictable.

Consider this function:

function total(price, quantity) {
  return price * quantity
}

If a hot call site repeatedly passes numbers, the engine may compile a specialized path guarded by assumptions about those values. If a later call passes something different, the guard fails. The engine falls back to more general code or compiles another version. That transition is commonly called deoptimization.

Deoptimization is a correctness mechanism, not an application error. The dangerous conclusion is that every changing type must be rewritten. Most functions are not hot enough for this detail to matter, and network, rendering, or algorithmic work often dominates instead.

Use this order when investigating slow JavaScript:

1. Record the real interaction.
2. Find a function with meaningful total time.
3. Check whether the algorithm repeats avoidable work.
4. Only then investigate engine-specific optimization behavior.

Microbenchmarks can mislead because they warm up one tiny function under artificial conditions. Test the complete user action and confirm that a code change improves its recording, not just an isolated loop.