Ingo talked about "Optimizing Performance and Scalability of Distributed .NET Applications", where he talked about what to look for, when searching for bottle necks in a distributed application.

A lot of the trouble exists on/with the database server. Some use Stored Procedures, because they say its faster. Lets assume that you have a table of 20 columns, where you want to update 3 of the columns, after a user has made some changes. Stored Procedures are usually constructed with a general perspective of how to update. This means the SP's are created to update every column in the table, and so you update a lot of columns, that didn't really need to be updated. Same thing is, when you use O/R mappers, you want to update some orders, and the orders have some items associated with them. When updating your orders, you have all the items associated with that order. Put it code:
Db db = new Db();
List<Order> orders = db.GetOrdersByCountryId(6);

foreach (Order o in orders)
{
  o.Attribute = 2;
  o.Items = db.GetItemsByOrderId(o.Id);

  foreach (Item i in o.Items)
  {
    i.ItemAttribute = 2;
    db.UpdateItem(i);
  }
  db.UpdateOrder(o);
}
The above code, would create an SQL statement for each update for both every order and item items, where Ingo's example showed around 650 SQL statements being sent to the server. Using SQL Server Profiler for SQL Server 2005, you can track what statements are sent to the server, and analyses whatever you want. Pretty neat tool, that I'll start using soon! Ingo was able to reduce the above statements to just about 10 queries!
So the message was/is: Don't use Stored Procedures, if your only argument is speed. Stored Procedures can be slower depending on their use.

Memory
Ingo showed a very cool program called CLR Profiler for the .NET Framework 2.0, where he was able to track what amounts of memory a specific call would use. You can use it for windows applications, ASP.NET sites and windows services. He used a couple of examples, but the most interesting ones was after his statement: "I am a perfect programmer". Assume that you are the best programmer in the world, you know all about when to use stored procedures and not, you know how to create a O(1) for sorting all kinds of threes and so forth. That maybe true, but always know, that you are using some other people components or code! This means, that even though you eliminate all scenarios of you messing up, some other people might be causing you some memory problems.
He gave an example of 3 companies, where they all supply a GridView-like control that enables sorting, column rearrangement, AJAX and so forth. By using the CLR Profiler, he was able to view, how much memory was allocated, when he searched for a specific country (Data from customers around the world). The first application used just over 24Mbs of RAM, the second used 17Mbs of RAM, and the last one used 2.4Mbs of RAM. This might seem like a lot, and it is! In comparison, he showed that the default GridView in .NET 2.0 used 41Kbs of RAM, when binding to an ObjectDataSource!

When Ingo posts his slides, I'll provide more info :)
Ingo rocks!