Because PostSharp is a compiler technology, most of the expensive work is done at
build time, so that applications start quickly and execute fast. When generating
code, PostSharp takes the assumption that calling a virtual method or getting a
static field is an expensive operation. Contrary to rumor, PostSharp does
not use System.Reflection at run time.
Aspect primitives such as OnMethodBoundaryAspect support a large set
of features, but concrete aspects typically use a fraction of those features.
The Aspect Optimizer scans the aspect code, finds which features are being used, and only generates necessary instructions to those features. Thanks to the optimizer, PostSharp can generate instructions that run as fast as hand-written code. In some cases, the code generated is so thin that the JIT compiler of the CLR can inline the aspect code inside the business code.
Will your build take longer with PostSharp? Probably.
However, each new version of PostSharp has been faster than the previous.
How much faster?
Here are the results measured by Bartek Legiędź and Remigiusz Cieślak, software engineers at Comarch in Poland. Their setup consists of a small number of very large projects (assemblies of several megabytes). As you can see, PostSharp 2.1 is more than five times faster than 2.0.
The next table compares the time taken by PostSharp while building the solution in two configurations (debug and release). Of course PostSharp itself ran in release mode both times.
| Build Configuration | 2.0 | 2.1 | Speedup |
|---|---|---|---|
| Debug Configuration | 160,662 ms | 21,293 ms | 672% |
| Release Configuration | 121,694 ms | 23,897ms | 571% |
The build time performance you will experience with your setup depends on several factors: size and number of projects, number of aspects, and hardware resources. Also, remember that PostSharp is only a part of the build process. With PostSharp 2.1, the build time may be dominated by the C# compiler or by Code Contracts.