One of the exciting new features in the next major release (code-named Pipestone), is the DekiScript Page Profiler.  I’m confident this new feature will delight many DekiScript developers.

In the past, it has been a hassle to figure what part of a complicated, dynamically rendered page requires the most attention.  Often, the only method was to comment out sections one by one to determine the offending line or page inclusion.  This is now a thing of the past.  The page profiler provides a detailed view of every single DekiScript function called and every page included.  It’s your backstage pass to see exactly what’s going on!

The profiler output is split into 4 summaries:

1. Rendered Content lists all the pages that were rendered and what functions were invoked on each page.  Function invocations are grouped together by location to show what each line is doing.  Additionally, each function includes an invocation count and total elapsed time.
2. Function Summary lists all functions invoked across all pages with their total elapsed time, total invocation count, average time, and max time.
3. Page Summary lists all pages with their total rendering time, inclusion count, average time, and max time.
4. Data Access Summary lists how many database queries were issued and the performance of the optional cache.

Obtaining the page profiler report requires directly accessing the API, a task that shouldn’t be a hurdleto DekiScript developers.

Here is how you get your page profiler XML document:

1. Identify the page ID of the page you want to profile.  The easiest is to look at the page source and look for the line that says:
   Deki.PageId = 123;
2. The page meta-data for any page can be accessed by its ID:
   http://mysite/@api/deki/pages/123
3. Now append /contents/explain and you’ll get the page profiler report:
   http://mysite/@api/deki/pages/123/contents/explain

Depending on how many operations your page performs, the returned XML can become fairly large, but that’s because it contains lots of details.  I would recommend looking at the function and page summaries first to get a sense for the potential culprits and use that information to track down the actual call that is causing the slowdown.

Finally, if your site your users report from sporadic slowdowns that you can’t reproduce, you can add this configuration key to have the profiler log its output when a page takes more than 3 seconds to render:

stats/slow-page-render-alert = 3.0

This will make it easier to capture those elusive moments where for some reason a page takes unusually long to render.

And remember when optimizing your pages: the fastest code is the one that never needs to run!