Sitecore developers know that part of the development process is to wait for Sitecore to respond after a change in a config file or dll, which sometimes can take a serious amount of time that some of us think is too much. For this reason, I wanted to take a look at this setting that a coworker recommended for reducing the waiting time:
<configuration>
<system.web>
<compilation ... optimizeCompilations="true">
</system.web>
</configuration>As you can see, the only thing you need to add is the attribute “optimizeCompilations” with the value “true” in the web.config of your site. I have to say this is recommended to be only done in your development machine and not on any QA, UAT or Prod environments because we want to gain some seconds in our development process, but this really doesn’t matter in those other environments.
Here are some numbers that came up as part of my tests that also help to show how the change improved the waiting time in my case.
Test: Change a config file
Waiting time before: 30 seconds approx
Waiting time after: 11 seconds approx
Test: Change a library within bin folder (dll)
Waiting time before: 19 seconds approx
Waiting time after: 10 seconds approx
These numbers can obviously change in your case, but it is also necessary to mention that I used a vanilla Sitecore installation 8.1 update 2 for the tests and I recycled the application pool after making the change in the web.config. One final thing just to be safe, is the numbers presented also depend of the power of your machine like RAM and CPU.
Like any good engineer, let’s dive into the details of how this is possible and an implication this change might have in some cases.
So, when you change a top-level file such as a config file or library (building a project) the .Net framework compiles these and stores them in its compilation cache stored in a temp folder of the server (%SystemRoot%\Microsoft.NET\Framework\versionNumber\Temporary ASP.NET Files). If you modify again one of these top-level files this causes that the framework clears its cache, rebuilds all affected resources and stores them again in the cache folder.
By changing this setting, we are avoiding the whole process and so the framework only compiles the affected files and leave the others without modification. We see a special benefit from this with Sitecore, because it uses a considerably amount of SPEAK renderings that are dynamically compiled on startup.
Now, it is important to be aware of some scenarios that could cause some issues by having this setting enabled.
The following was extracted from a MSDN article first mentioned in the reference section.
- Renaming or deleting methods or properties. If the affected member is referenced by an already-compiled page, an exception will be thrown.
- Changing the signature of a method, or the type of a property. If the affected member is referenced by an already-compiled page, an exception will be thrown. Some signature changes would not cause compile or run-time errors if the whole site is recompiled. For example, the code Response.Write(ClassA.MethodA() in an .aspx page will compile and run fine whether MethodA returns an int or a short. But if the .aspx page is already compiled and you change the return type of MethodA from int to short without recompiling, a runtime exception will be thrown because the compiled code expects the int signature.
To conclude, I think this is a good-to-know tip to apply when you are fixing a bug or developing a feature that seems to be located in only one project of the solution or touches couple of views in the same. However, if you are touching more than one project, I suggest you have an eye open in case you see a run-time error to first remove this setting since this most probably could have happened because of it and then rebuild the solution.
Reference:
Dave Coding 