Michael analogizes debugging to a murder mystery:

Here's some advice from me. Whether you choose to apply it to debugging a coding problem, or just understanding general behaviour that a program is exhibiting, try doing the follow:

Assume the entire issue is like a murder mystery. First you need to establish a motive. You also need a means and you need opportunity.

When debugging, it is easy to guess at some components motive and jump straight to their guilt. For the ultra intuitive, this can often work out really well. But for everyone else, it leaves them stumped as to what went wrong when jailing the component does not stop the crime from repeating.

My summary: Don't guess. In my experience, developers (myself included) are notoriously bad at figuring out where problems lie - this is especially true when the subject is "why is it slow?" Walk through the code with a debugger, or - in the case of a performance issue - use the profiler.