With particular reference to database queries, if you're using .NET with SQL Server you're better off keeping the SQL Server Profiler open on one monitor with:
* Showplan XML (Statistics Profile)
* SP:StmtCompleted
* SQL:StmtCompleted
(I think there's an RPC:StmtCompleted that's useful in some circumstances but I don't use it.)
Personally I pay more attention to the execution plans [1] than execution times, unless you have lots of data (indicative of what's on your production database) in your development database all your queries will complete quickly (table scans, nested loop joins and all).
You also see the N+1 problem very quickly when you're presented with a wall of trace results.
This isn't a silver bullet, but it's been a very long time since I've let any significantly suboptimal query get to production.
[1] Some difficulty arises with small development databases, because SQL Server will frequently scan a clustered index instead of a non-clustered index + clustered seek/key lookup because it's quicker to do the one thing. In this case you have to understand that the query is not bad and treating the clustered index scan as "bad" is not correct.
* Showplan XML (Statistics Profile)
* SP:StmtCompleted
* SQL:StmtCompleted
(I think there's an RPC:StmtCompleted that's useful in some circumstances but I don't use it.)
Personally I pay more attention to the execution plans [1] than execution times, unless you have lots of data (indicative of what's on your production database) in your development database all your queries will complete quickly (table scans, nested loop joins and all).
You also see the N+1 problem very quickly when you're presented with a wall of trace results.
This isn't a silver bullet, but it's been a very long time since I've let any significantly suboptimal query get to production.
[1] Some difficulty arises with small development databases, because SQL Server will frequently scan a clustered index instead of a non-clustered index + clustered seek/key lookup because it's quicker to do the one thing. In this case you have to understand that the query is not bad and treating the clustered index scan as "bad" is not correct.