Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Found a nice explanation of this <a href="http://chiragrdarji.wordpress.com/2007/10/12/page-ghosting-unghosting-and-effect-of-pageghosting-on-performance-in-sharepoint-2007/" rel="nofollow noreferrer">1</a>:</p> <blockquote> <p>As a developer, your initial reaction to this might be to question why customized pages are processed in no-compile mode. Your instincts likely tell you that compiled pages run faster than no-compile pages. However, no-compile pages can be more efficient and more scalable in certain scenarios. This is especially true in a large WSS environment where the number of customized pages can reach into the thousands or tens of thousands. </p> <p>No-compile pages can be loaded into memory and then unloaded in a manner that is not possible for compiled pages because the .NET Framework doesn’t really support the concept of unloading an assembly DLL from memory. The closest equivalent would be to recycle the current Windows process or the current .NET AppDomain. However, this type of recycling involves unloading all assembly DLLs from memory, not just those assembly DLLs that haven’t been used recently. Furthermore, the .NET Framework places an upper limit on the number of assembly DLLs that can be loaded into a .NET AppDomain. </p> <p>No-compile pages provide higher levels of scalability because they do not require loading new assembly DLLs or managed classes into memory. Instead, the processing of no-compile pages involves loading control trees into memory. WSS can manage the memory usage for the control trees associated with customized pages more efficiently because they are not compiled into assembly DLLs. For example, once WSS has finished processing a customized page, it can unload the page’s control tree to free up memory for other purposes. Furthermore, no-compile pages eliminate the need to go through the compilation process, which actually provides faster response times for pages upon first access.</p> </blockquote> <p>They key takeway is simply that no-compile pages can be unloaded (the associated page builder can be unloaded), which isn't possible with compiled pages. At its core though, this is a scalability measure (more pages can be handled under this model) and not a performance enhancement (after initial setup, compiled pages should perform better than their non-compiled counterparts). </p> <p><a href="http://chiragrdarji.wordpress.com/2007/10/12/page-ghosting-unghosting-and-effect-of-pageghosting-on-performance-in-sharepoint-2007/" rel="nofollow noreferrer">1</a> - <a href="http://chiragrdarji.wordpress.com/2007/10/12/page-ghosting-unghosting-and-effect-of-pageghosting-on-performance-in-sharepoint-2007/" rel="nofollow noreferrer">http://chiragrdarji.wordpress.com/2007/10/12/page-ghosting-unghosting-and-effect-of-pageghosting-on-performance-in-sharepoint-2007/</a></p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload