Yes, but before I do, your original email opens up a bigger issue, I think. To demonstrate, let me ask: Does anybody really use a debugger? You see, I think that any real software engineer should be able to write bug-free code and if looking at someone else's code, should be able to identify the bugs in a fairly straight forward process. Pretty silly, right? Of course this is tonge-in-cheek, but the point is that a profiler is a tool that has a place in the engineer's toolbox. By asking the question in a way that belittles the use of the tool, it seems the results of the answers will be biased, or at least the interpretation of the results will be. (Full disclosure: Maybe there are a few who are so good they can optimize their code without a profiler, but I have learned the hard way that I am not one of those - I also used to believe profilers are for the weak.) Engineers use tools. Engineers use data from experiments to test their products and, maybe, improve them. Ignoring a tool doesn't make sense to me. I agree that profilers can be hard to use and produce a lot of noise, but using a lathe is hard, too, until you understand how to get good results from it. A profiler is not the primary tool, to be sure, but there are cases where it can be Indispensable (and has been to me). Here are where I think it makes a lot of sense: 1) Education: How does one get experienced in performance analysis and tuning with C#. And how to we know we are right? Sure, moving the invarient out of the loop make it run faster, but are there other things we could/should have done, as well? Profilers are a great way to learn where the bottlenecks are, especially when working with a new language or in a new environment. One line of code taking 85% of my runtime? How do I know it's that one? (Linq is an easy target, but what about your enum example? How do you know the first time?) I've had experiences similar to yours where I see something obviously bad and let the designer know only to be told "no way it's my problem"; When I show them profiling output proving they are the problem, they start to listen. Data are powerful things! 2) Real-time systems: I think much of the discussion on this thread has been about business-logic type applications. Large databases, searching, etc. But what if you are building a real-time processing system with streaming data in one thread, real-time analysis/processing in another and real-time display in a third (and it's actually much more complicated that that in real life as those t