We received an excellent bug from Michael Teper commenting that rename was taking too long in a scenario that should have been faster.  Not only does he mention his dissatisfaction but he also took the time to suggest a way that we could be much faster in a very specific renaming scenario.  Specifically, if you were renaming a private field then it shouldn't be necessary to compile the full solution.  First off, i want to thank Michael for submitting this feedback to us.  It's extraordinarily helpful to know if our features are or are not meeting your needs.  When we don't hear anything from users we will often have to guess or hope that it's working out well.  (and, sometimes you want something to be working so well that users never even notice it).  However, when we do hear back from a user we know that this is something we have to look at.  Now, i wanted to dive deep into the optimization suggestion that was made.

Specifically, Michael says "This class lives in a library project that depends on one other library project. Current implementation aside, I can't see any reason why you would need/want to compile the entire solution just to analyze usage for a *private* field."

This is a very reasonable complaint.  It certainly appears that if you had the following code:
internal sealed class TextBoxDefinition : FieldDefinitionBase {
private int _maxLength;

public int MaxLength {
get { return _maxLength; }
set { _maxLength = value; }
}
}

and you renamed "_maxLength" to something else (say "_maxSize"), then we could put in a quick optimization and and only try to compile the current type.  The reasoning behind this is that as the field is private, nothing else could possibly reference it and so it suffices to look in the current type only when doing the compile.  However, as it turns out this is not the case.  And it is necessary when renaming a member (even a private one) to do a full project analysis.  Why?  Well consider the following trivial example:
public class Foo {
private int member;

void Method() {
Bar.CreateFoo().member = 4;
}
}

public class Bar {
public static Foo CreateFoo() {
return new Foo();
}
}

As you can see, "member" is referenced in one place:
Bar.CreateFoo().member = 4;

This is an example of referencing a private member of the current type through an expression that binds to an instance of the current type.  However, in order to know that "Bar.CreateFoo()" binds to an instance of "Foo" we must compile "Bar".  Since arbitrary expressions can end up returning an instance of the current type we basically need to compile everything to ensure that accurately rename everything.

Now, one area that we can we can speed this up in is when you rename a local variable.  Because the local variable cannot be referenced by anything outside the current member, and because you can only refer to it with it's name and not through an arbitrary expression, it's possible to rename a local quite quickly.

When we started work on refactorings we read a lot of the literature on it, and we talked to many customers to see what they wanted out of it.  And the message we got back was that if they could not absolutely trust refactorings then they would not use them.  Refactorings are supposed to keep the semantics of your code the same and if that invariant is not held, then refactorings like renames are no better than just a find/replace.   And, like with most development, and especially something like refactorings, it was our top priority to get the feature working to specification first, and then make it work performantly next.   So, for whidbey, we will continue to rebuild a fair bit when you rename a class member (private or otherwise).  However, it's still possible for us to find other ways to make this faster through other means, and we'd like to make these kinds of user actions much faster for our RTM release. 

Michael: Once again, thank you very much for your feedback.  We'll definitely be keeping that bug open so that we can track the issue of performance with this feature.  I hope that when we finally ship you'll be much happier with the product!