Chasing Performance: How I Found and Fixed a Hidden Bottleneck

The Unexpected Slowdown

It all started on a regular workday when I was debugging a feature in our application. Users were complaining about delays and timeouts, and I was on a mission to uncover the culprit. At first, nothing seemed out of the ordinary—no complex algorithms, no massive database queries, just simple operations.

But the numbers didn't lie. Something was slowing things down, and it was time to dig deeper.

Profiling the Code: A Peek Under the Hood

To get to the root of the issue, I fired up CPU profiling. Profiling is like putting a magnifying glass over your code execution, helping you see where time is being spent.

As the profile results loaded, my eyes locked onto a flame graph. This visualization showed deep red spikes in a seemingly harmless function: an array lookup using indexOf(). The deeper I looked, the clearer it became—this innocent-looking operation was eating up precious milliseconds on every request.

That’s when it hit me: Time complexity matters.

Preventing Duplicates: The Cost of indexOf()

The purpose of indexOf() in our code was to prevent duplicate entries before adding elements to an array. The logic was simple—before inserting a new element, we first checked if it already existed:

const values = [];
const newItem = "test";

if (values.indexOf(newItem) === -1) {
    values.push(newItem);
}

At first glance, this seemed like a harmless approach. It worked well with a small dataset, ensuring that no duplicates were added. However, when our data grew to millions of elements, things took a turn for the worse.

Each time we inserted a new item, the indexOf() function had to scan the entire array to check for its existence. Since indexOf() performs a linear search (O(n)), the lookup time increased as more elements were added. This meant that as the array grew, every insertion became slower, turning what should have been a simple operation into a major performance bottleneck.

The Fix: Replacing Array with Set

Realizing this inefficiency, I decided to replace the array lookup with a Set. Unlike arrays, Set objects store unique values by default and provide O(1) lookup time, making them ideal for preventing duplicates:

const valuesSet = new Set();
const newItem = "test";

valuesSet.add(newItem);

With this simple change, we eliminated the need for explicit duplicate checks. The Set.add() method inherently prevents duplicates and operates in constant time, meaning it performs equally well whether we have 10 elements or 10 million.

The Real Impact: Scaling to Millions of Elements

Initially, the difference was barely noticeable when dealing with small datasets. But when we scaled up to millions of entries, the impact was profound:

• Before (Using indexOf): Every new insertion required scanning an increasingly large array, making each operation slower and compounding the performance issue.

• After (Using Set): Insertions became instantaneous, as duplicate checks were handled in O(1) time complexity, regardless of dataset size.

By simply switching from an array to a Set, we were able to reduce lookup and insertion times from O(n) to O(1), making our system significantly more efficient.

---

More Than Just One Fix: A Mindset Shift

This wasn’t just about replacing indexOf. It was about thinking critically about performance, questioning assumptions, and using the right tools:

1. Profiling first, optimizing second – Never optimize blindly. Tools like CPU profiling and flame graphs tell you where time is actually spent.

2. Understanding time complexity – Choosing between O(n) and O(1) operations can mean the difference between sluggish and snappy applications.

3. Picking the right data structures – Arrays, sets, maps, and objects all serve different purposes. Knowing their strengths and weaknesses is key to writing efficient code.

---

The Takeaway: Write Smarter, Not Harder

Performance optimization isn’t about memorizing tricks—it’s about developing a mindset. Since that day, I’ve made it a habit to profile my code before optimizing, question inefficient operations, and always look for the best tool for the job.

So next time your code runs slow, don’t guess. Profile it. Analyze it. Fix it.

Happy coding! 🚀