The problem
Template profiling can be extremely helpful in diagnosing performance problems with templates. Currently profiling is a global CMS flag and causes ALL templates to be profiled. This results in a reluctance to enable profiling which is detrimental to enabling developers to investigate template performance issues because of the following challenges:
- Profiling results in a template performance hit due to the time and storage costs associated with the profiling.
- Profiling ALL templates causes system-side performance hit.
- Profiling ALL templates results in large amounts of unused profiling data being collected.
- Profiling data is mixed between all template handlers / files (input, output, post_input, post_save etc.)
The suggestion
- Create a new Template API class / method that would enable template profiling per context and per template: OutputContext.EnableProfiling() or InputContext.EnableProfiling() for example.
- Store and expose profiling data per run. This could be a presented as a report or table view much like the system audit log.
- Create a new system access control property "Enabling profiling".
- Only enable profiling if the user is in a group that has the "Enable profiling" permission. The purpose of this is to prevent unnecessary profile code being run if developers leave code enabling profiling in a template that is then being run by content editors.