Conditional Breakpoints are Slow

An entry about visual studio Publication date 20. September 2007 11:08

Today I was dumbfounded by a part of code I was working on slowing down significantly without there really having been made any major changes to it. Turns out that I had left a conditional breakpoint active:

image

The breakpoint above was being evaluated several thousands of times in a tight loop - I just didn't notice because the condition was never true. I really wish the Breakpoints window (Ctrl+Alt+B) had a column showing the number of times a breakpoint had been evaluated.

The moral of the story - know the things that may severely impact performance during debugging.

Be the first to rate this post

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Comments

Powered by BlogEngine.NET 1.4.5.0

Welcome!

My name is Fredrik Kalseth, and this is my blog - thanks for visiting! I am fortunate enough to work with what I love for a living, and this blog is essentially the biproduct of that.

I work as a senior consultant for Capgemini, and am also an active participant in the Norwegian .NET community, as an avid attendee but also as a speaker (most recently at NNUG and MSDN Live).

As a developer, I have a wide circle of interest. My primary passion is for agile, test-driven development, with focus on best practices and clean code. That said, I also love to work on the frontend, especially with web development.

On Twitter? My handle is fkalseth. On LinkedIn? I`m there too.

NDC 2010

The conference to attend this summer happens June 16th-18th in Oslo, Norway. Are you going? Be sure to catch my talk on AOP while you're there!

 

Disclaimer

This is a personal blog; any opinions expressed here are my own and do not necessarily reflect those of my employer. All content herein is my own original creation, and as such is protected by copyright law. Unless otherwise stated, all source code posted on this blog is freely usable under the Microsoft Permissive License.

What Readers Talk About

Comment RSS