One of the thing I learn about in programming is that, if you have to use debuggers too often then maybe it's a good time to re-evaluate on how you develop a project.

1. Did you misunderstand the pattern design?
2. Were there something you don't understand?
3. Maybe it's an indication that you need to document more and do some project designs before committing the implementation?
4. Were the way you write code more prone to bugs?
5. Are there any libraries or tools that can help you alleviate this?

By fixing your practice and making it less prone to bugs, you wouldn't have to resort to using debugger as often.

As for profilers, it really depends, but generally if you try to be conservative like applying lockless concurrency where possible and sometime resorting to mutex/semaphore if otherwise needed, you should generally be ok when dealing with concurrency situation. As for overall performance, the rule of thumb is that, the less code you run to do the work, the better. You can see what program would actually do when dealing with C language for instance, but you might have a harder time to make such evaluation on higher level languages, so the general wisdom is that the heavy computation operation should be deferred to low level language like C language and you should have high level language calls into that C function to handle those performance intensive operations.