If you break the rules, have good reasons
And document themRico Mariani posted another Performance Quiz last month (I meant to post this earlier, but I didn't get to it).
In this installment, he discusses the performance benefits of a struct with public fields.
He broke the rules in the Annotated Design Guidelines, and many in Effective C# as well. That's fine, because everytime he broke one of the rules, he has a specific and clear reason for it.
That gets to the point of my post: If you break the guidelines in your code, the burden of justification is on you. You have to have a reason, and that reason has to be based on darn good reason. Finally, if that reason is performance, there better be some data behind your assertions that breaking the rules made it faster.
Of course, on the other side, the nature of creating guidelines and advice books (like Effective C#) is that no matter what you say, there are almost always edge cases or other conditions where the advice doesn't apply. So we authors have a choice: document all the edge cases and fill our books with digressions away from the main topic, or assume you'll know when you see them. In most cases the latter is preferred. I've certainly taken that course, and Rico, with his emphasis on performance, will often point out different times when the standard guidance can have a negative effect on performance. We're both right, it just depends on the goals.