When talking about PostSharp's performance, one should always two aspects of the problem in mind: compile-time performance, and run-time performance.
Run-time performance very much depends on which plug-ins you use, and how you use them. However, it is not the subject of the current section: we will focus on compile-time performance.
The first thing to note is that what PostSharp does is inherently complex: PostSharp (and plug-ins running inside PostSharp) typically perform complex analysis on assemblies composed of thousands of methods and hundreds of thousands of instructions. Although algorithms and data structures have been fine-tuned for speed and reasonable memory consumption, we should align our expectations with reality: we are doing complex things, and it's not going to be instantaneous.
There are, however, some factors we have influence on are improving assembly load time and using the release build.
Improving Assembly Load Time
Since PostSharp is typically invoked very frequently and has a very short lifetime, assembly load time and JIT compilation have a tremendous importance on PostSharp overall compile-time performance, especially if you have a large number of small projects. Here is what we can concretely do to reduce load time:
- Generating native images using NGen. This is the default configuration if you installed PostSharp using the Windows Installer. Note that native images cannot be used when the PostSharp MSBuild task is used. For this reason, the command-line utility is used by default by PostSharp targets for MSBuild.
- Installing all assemblies in GAC. It can be used in combination with generation of native images. However, because it is considered as a bad practice to install application-specific assemblies in GAC, we do not use this possibility.
- Avoid creating new OS processes. Clearly, this means that we should gain from using the MSBuild task instead of the command-line utility. However, native images will not be used by MSBuild.
The following table compares, for different deployments, the time spent in PostSharp while building all samples.
| GAC | NGen | Host | Result |
|---|---|---|---|
| Yes | No | Command Line | 109% |
| Yes | No | MSBuild | 100% |
| No | No | Command Line | 113% |
| No | No | MSBuild | 189% |
| No | Yes | Command Line | 109% |
As you can see, the best combination seems GAC, MSBuild and no NGen (chosen as the reference score with 100% of time). The combination that is configured by default by the installer, NGen + Command Line, is 9% slower, but follows best practices.
Using the Release Build
Our download page encourages you to install the release build of PostSharp and PostSharp Laos. These builds are considerably (25%) faster than the debug builds. Indeed, release builds do not contain precondition checks (implementing defensive programming) and tracing logic. They are therefore also less safe.
If you are an end-user of PostSharp, we recommend you installing release builds. However, if you program directly with PostSharp Core, you will find yourself much more productive by using the debug builds.