arr1 = [1, 3, 2, 1, 4, 5]
arr2 = [3, 2, 2, 1, 1]
answer = [3, 2, 1]

simple enough right? and if you've done even a little bit of DSA prep your brain immediately goes - HashSet.

put all elements of one array into a set, iterate over the other, call .contains(), done. O(1) lookup, O(n) total. clean. elegant. textbook optimal.

and then there's the other approach - the sorting one. sort both arrays, use two pointers, skip duplicates, collect common elements. something like this:

Arrays.sort(arr1);
Arrays.sort(arr2);
int n1 = arr1.length;
int n2 = arr2.length;
int i = 0, j = 0;

while (i < n1 && j < n2) {
    // skip duplicates
    while (i > 0 && i < n1 && arr1[i - 1] == arr1[i]) i++;
    while (j > 0 && j < n2 && arr2[j - 1] == arr2[j]) j++;

    if (i >= n1 || j >= n2) break;

    if (arr1[i] == arr2[j]) {
        ans.add(arr1[i]);
        i++;
        j++;
    } else if (arr1[i] > arr2[j]) {
        j++;
    } else {
        i++;
    }
}

and this one? O(n log n) because of the sorting step.

so naturally, solution 1 wins. O(n) beats O(n log n). case closed.

...right?

well, not exactly

so here's the thing that completely messed with my head. i was reading through a well-known programming book and found actual benchmark data comparing both approaches. real numbers, real hardware. and the results were... uncomfortable.

read that again.

the O(n log n) solution is consistently faster than the O(n) solution. and the gap doesn't close as n grows - it actually gets worse for the HashSet approach.

what?

if you're sitting there thinking "that can't be right, O(n) is literally a smaller function than O(n log n)" - yeah, that's exactly what i thought too. and that's exactly why this is worth writing about.

because here's the uncomfortable truth: Big-O notation tells you how an algorithm scales. it doesn't tell you how fast it actually runs.

so what's actually going on?

to understand this, you need to understand something about how your CPU actually works - specifically, how it reads data from memory. and trust me, once you get this, you'll never look at algorithm analysis the same way.

your CPU doesn't read from RAM - it reads from cache

your CPU has a multi-level memory hierarchy. think of it like this:

look at that gap between L1 and RAM. that's roughly a 50-100x difference. reading from RAM is not just "a little slower" - it's a completely different universe of slow compared to reading from cache.

and here's the key mechanism that makes this matter: cache lines.

when your CPU needs to read arr[i], it doesn't just fetch that one element. it fetches an entire cache line - typically 64 bytes of contiguous memory. so if your array elements are 4-byte integers, one cache fetch pulls in the next 16 elements for free.

so when you access arr[0], the CPU automatically pulls arr[0] through arr[15] into L1 cache. now when you access arr[1], arr[2], arr[3]... they're all already there. zero wait time. this is called spatial locality - accessing nearby memory locations in sequence.

now let's look at what happens with each approach

sorting - the cache's best friend

merge sort and quicksort access array elements sequentially or in predictable patterns. the CPU's prefetcher sees this pattern and starts loading the next cache line before you even ask for it.

so the two-pointer traversal after sorting? pure sequential access. arr1[0], arr1[1], arr1[2]... every single access is a cache hit. the data is already sitting in L1 by the time the CPU needs it.

this is what we call cache-friendly access. the hardware is literally optimized for exactly this kind of pattern.

HashSet - the cache's worst nightmare

now think about what a HashSet actually does under the hood.

when you insert a value, the hash function computes a hash code and maps it to a bucket. the thing is - hash functions are designed to scatter values uniformly across memory. that's literally their job - to distribute things randomly so you get even bucket distribution.

but "randomly distributed across memory" is the exact opposite of what your CPU cache wants.

every single .contains() call goes something like:

1. compute hash → jump to some random bucket

2. follow a pointer to the node → another random memory location

3. compare the value → maybe follow another pointer if there's a collision chain

each of these jumps is likely a cache miss. the CPU has to go all the way to main RAM. 50-100 nanoseconds. per lookup.

and it gets worse. because HashSet in Java uses a linked structure internally (buckets with nodes/trees), you're chasing pointers all over the heap. the CPU prefetcher has absolutely no idea where you're going next. it can't help you.

so your "O(1) lookup" is technically O(1) in terms of comparisons - but each comparison costs 50-100x more wall-clock time because it's hitting RAM instead of cache.

the hidden constant that Big-O hides

this is the thing they don't really emphasize in most DSA courses.

when we say an algorithm is O(n), what we actually mean is the running time is c × n for some constant c. and when we say O(n log n), it's k × n × log(n) for some constant k.

Big-O drops those constants because "they don't matter asymptotically." and that's mathematically true. but in the real world, on real hardware, the constants are where your program actually lives.

for the HashSet approach:

• c includes: hash computation, random memory access (cache miss), pointer chasing, collision handling

• each operation might cost ~100-200 ns due to cache misses

for the sorting approach:

• k includes: comparisons and swaps on sequential data (cache hits)

• each operation might cost ~1-5 ns because everything is in cache

so the real comparison isn't n vs n·log(n). it's:

HashSet:  200 × n
Sorting:  3 × n × log(n)

at n = 5,000,000:

HashSet:  200 × 5,000,000             = 1,000,000,000
Sorting:  3 × 5,000,000 × 22.3       =   334,500,000

sorting wins by 3x. which is almost exactly what the benchmark data shows.

so does this mean HashSet is bad?

no. absolutely not.

HashSet is still the right choice in a lot of scenarios - especially when:

• your dataset fits comfortably in cache

• you need frequent lookups against a relatively static set

• you're doing set operations (union, intersection) on smaller collections

• the alternative would require repeated sorting

the point isn't "never use HashSet." the point is: don't blindly trust Big-O as a performance guarantee.

Big-O tells you the shape of the growth curve. it does not tell you:

• the constant factor (which can be 100x different)

• the cache behavior (which dominates real performance)

• the memory allocation overhead

• the branch prediction patterns

the one-line takeaway

O(1) with a cache miss can be slower than O(log n) with a cache hit. the hardware speed gap between cache and RAM is so massive that it can completely overwhelm algorithmic advantages.

next time you're choosing between a hash-based approach and a sort-based approach, don't just compare the Big-O. ask yourself: how is my CPU actually going to access this data?

because sometimes the "slower" algorithm is the faster program.

if you found this interesting, i'm planning to write more about the gap between theoretical CS and what actually happens on real hardware. things like why linked lists are almost always slower than arrays in practice (same cache story), and why B-trees beat binary search trees for databases. follow along if you're into this stuff.