Performance and optimization

Where does the time go?

The first step in dealing with any performance problem is to measure the form and see where the time is going.

XSLTForms includes a built-in profiler and debugger, which can be made visible by including the processing instruction <?xsltforms-options debug="yes"?> at the top of your document, or (normally) by pressing F1 in a desktop browser. At the top of the screen, the label "Debug mode" will appear, together with version information and the reminder "Press F1 to toggle mode." Below the "Debug mode" heading two buttons will appear, labeled "Profiler" and "Trace log".

Clicking on the "Profiler" button will cause a time profile for the form to be opened in a new tab or window. Among other things it will show the cumulative time spent evaluating all the XPath expressions in the form. In some cases, a very small number of expressions consume a large percentage of the evaluation time; the profiler allows optimization effort to be concentrated where it will do the most good.

[Some general advice on optimization would be useful here. Use subforms, exploit locality, etc.]

Does running the XSLT transform in the client slow things down?

Tests and performance measurements show that the XSL transformation time is very short, whatever the browser.

The time to initialize the structures of the XPath interpreter and processing of interactions with the user depends on the performance of the browser's JavaScript engine.

Some results here: http://www.web21th.com/samples/performances.htm [No longer available, February 2017]

These tests were made in May 2009, with some modifications in XSLTForms source in order to introduce probes.