This file covers runtime behavior that matters in advanced interviews: memory leaks, garbage collection, rendering cost, and optimization decisions.
Performance work starts with measurement. Memory problems usually come from unintended object retention, not from the language randomly wasting memory.
- JavaScript engines use automatic garbage collection.
- Objects that are no longer reachable can be collected.
- Reachability is the key idea, not manual freeing.
- Forgotten event listeners
- Long-lived timers
- Closures retaining large objects unnecessarily
- Detached DOM nodes still referenced in code
- Unbounded caches
A memory leak in JavaScript usually means something is still reachable when it should have been released, so the garbage collector cannot clean it up.
Use when a function should run after rapid activity stops.
Use when a function should run at most once per interval.
- Debounce search input
- Throttle scroll or resize handlers
- Minimize unnecessary DOM updates.
- Batch work when possible.
- Avoid layout thrashing.
- Use virtualization for large lists.
Even in frontend work, poor Big-O choices can make the UI slow before rendering even starts.
I profile first, identify the real bottleneck, and then choose the narrowest fix instead of applying generic micro-optimizations everywhere.
Unintended object retention through references that never get released.
Debounce waits until activity stops. Throttle limits how often work can run.
Because otherwise you may optimize the wrong thing and add complexity without improving user experience.