 <p>Compilation is slowed down a bit because of the way that CodeContracts work. There is an IL re-writer that injects code into your methods based on the contracts that you specify. This happens after the C# compiler has come along and generated the IL for your assembly. </p> <p>The runtime performance difference is quite small and will not affect your code in a noticeable way. Unless you are developing some real-time stock trading system, I seriously wouldn't even worry about it.</p> <p>As far as disabling Code Contracts in Production, I would far rather have the added protection of Code Contracts that some possibly obscure error. An error in the code contract will tell you exactly where and why the Contract was violated as opposed to having to dig down in some deep call-stack just because some bad data was passed in 5 levels up the call-stack tree.</p> <p>If you are using or are planning to use <code>Contract.Requires&lt;TException&gt;</code> and do not enable 'Runtime Contract Checking', you'll get a runtime failure about the IL rewriter needing to be bound to the usage of Code Contracts. You will then be required to enable Runtime Contract Checking to get this to work.</p> <p>IMHO, the use of <code>Contract.Requires&lt;TException&gt;()</code> is far more useful than <code>Contract.Requires()</code> since you have control over the type of exception thrown.</p> <p>EDIT: One thing I forgot to add is that the IL Rewriter is completely independent of the C# compiler and there are no dependencies between the two.</p>