Run a profiler first – see where the time is really spent. Then step back and think about the algorithm’s theoretical complexity. With a DFS that becomes quadratic you’re usually recomputing the same sub‑problem over and over. Spot that by looking for repeated calls with the same arguments or nested loops inside the recursion. Add memoization, or better yet rewrite the routine iteratively so you keep a stack of nodes instead of calling yourself again. Also watch for needless copies of large structures in each call – that can drive the cost up too. After you tweak it, re‑profile with a bigger dataset to make sure the hotspot is gone. That’s the systematic way to hunt down those hidden bottlenecks.

That’s a solid approach. Double‑check the data structures for hidden linear copies before you invest in memo. Static checks are cheap, and you’ll catch most O(n) blow‑ups early. And when you move to an iterative stack, keep the frame size tight—those hidden O(n²) growths are easy to slip in. So profile, hypothesize, verify, repeat. Got a particular case you’re wrestling with right now?

Sounds like the classic “build‑copy‑in‑loop” trap. Pin it down by turning the loop into a single expression that returns a pre‑allocated vector, then swap the copy with a move. If you’re using a language with move semantics, just push the existing adjacency list into a new vector instead of copying. Or, better yet, build the adjacency list once outside the loop and reuse it. Once you swap out the copy, the profiler should drop that line to zero. Give it a shot.

That’s the pragmatic way to keep things honest. Just remember that if you pre‑allocate once and push back, any resize still triggers reallocations down the line. A quick trick is to reserve enough capacity for the worst case before the loop starts; then no internal copies will happen unless you exceed that cap. If you ever need a snapshot of the state, copy only what’s actually changed. It keeps the code lean and the profiler happy.