Balisage Paper: Achieving Near-Native Performance in XSLT, XQuery, and XPath Using Host-Language User Extension Functions

Introduction and Motivation

The motivation for this work stems in part from Cython, a superset of Python that enables developers to achieve performance closer to that of C while retaining much of the Python programming model CYTHON.

The performance gains of Cython are achieved through several mechanisms. Firstly, Cython allows variables, function parameters and return values to be declared using static C types, reducing the overhead associated with Python's dynamic type system. Secondly, statically typed values can be compiled directly in C, avoiding runtime type checks and object allocations. Thirdly, Cython can invoke C functions and libraries directly, bypassing the Python interpreter for computationally intensive tasks. The generated code remains interoperable with the Python runtime and object model.

The final point mentioned above is particularly relevant to this work because it parallels the way SaxonC integrates Python extension functions with XSLT, XQuery, and XPath (Details on the Saxon variants, see Appendix A). In both cases, computationally intensive operations can be delegated to Python code while remaining accessible from a higher-level programming environment.

There are other tools that mix host language functionity too. For example, the XForms implementation Saxon-Forms SAXONFORMS was built using SaxonJS to run in web browsers. The extensibility of Saxon-Forms is important for certain applications, where some XForms functions not in the XPath specification are implemented as user-defined functions written directly in JavaScript. The paper also describes the use of application logic implemented in JavaScript to meet the needs of its users. These functions can then be imported and invoked from XPath expressions used within XForms applications.

This raises an interesting question for XML technologies: can host-language extension functions provide similar benefits for XSLT, XQuery, and XPath applications, allowing developers to preserve a declarative XML-processing architecture while selectively benefiting from the performance characteristics of native languages?

The experimental analysis presented in this paper focuses on SaxonJ and SaxonC (specifically the commercial products - named as EE). SaxonJ is implemented entirely in Java and is designed to run on a traditional JVM. SaxonC, by contrast, is built using GraalVM Native Image technology (AOT compiler) GRAALVM, a JVM implementation capable of compiling Java applications ahead of time into native code and packaging them as shared libraries.

Effectively, a lightweight VM runtime executes within the native library, allowing native applications to invoke functionality implemented in Java. This enables applications written in other languages, such as in C and C++, to call Saxon without requiring a separate Java installation.

The resulting binary includes the compiled SaxonJ code together with the required JDK libraries and runtime components needed to execute the native image. Creating a native image offers several advantages, including a C/C++ API, faster startup times, lower resource usage, greater flexibility when integrating with other programming languages, and simplified deployment and packaging. In addition to its C and C++ APIs, SaxonC provides language bindings for Python and PHP.

Before presenting our experimental analysis and results, we first describe how extension functions are implemented in Saxon. The discussion focuses on SaxonJ for Java and SaxonC, which adopts a different approach to integrating and supporting host languages such as C++, Python, and PHP. We then detail our experimental design, performance analysis and discussion of results then finally conclusion on findings.

User Extension Function Implementations

Extension functions allow code written in a host programming language (for example: Java, C++, Python or PHP) to be invoked directly from a function call in an XPath expression (whether in XSLT, XQuery, or pure XPath). For this to work the Saxon processor needs to be able to locate the executable code corresponding to a particular function name. The function arguments need also to be available and are passed as either XDM types or converted to the host language type system, with the opposite conversion applied to the return value of the function.

XdmValue * calculate(int argc, XdmValue ** argv) {

    long iterations =
        ((XdmAtomicValue *)argv[0]->getHead())->getLongValue();

    double otherData =
        ((XdmAtomicValue *)argv[1]->getHead())->getDoubleValue();

    double result = 0.0;

    for (long i = 1; i <= iterations; i++) {
        result += std::sqrt(static_cast<double>(i)) + otherData;
    }
    return processor->makeDoubleValue(result);
}

proc->registerUserFunction("www.host-lang-func.com", &calculate,
    "{ \"calculate\": {"
    "      \"as\": \"xs:double\","
    "      \"param\": ["
    "        \"xs:integer\", "
    "        \"xs:integer\""
    "      ],"
    "      \"arity\": [2]"
    "    }"
    "}");

    xmlns:func="www.host-lang-func.com"

    <xsl:template name="funcCall">
        <results>
            <!-- Repeat the expensive function 100 times -->
            <xsl:for-each select="1 to $rpt">
                <run number="{.}">
                    <xsl:value-of select="func:calculate($input, .)"/>
                </run>
            </xsl:for-each>
        </results>
    </xsl:template>

Experimental anaylsis

In this section, we present a number of examples. For each of them we compare the execution time performance of a pure XSLT stylesheet that uses the xsl:function instruction to perform a task with an equivalent modified XSLT stylesheet that perform the same task using a user-defined extension function. To broaden the scope of the experiments, we execute the stylesheets in Java, C++, and Python implementations. This is achieved through the SaxonJ s9api and SaxonC APIs, with equivalent user extension functions implemented in each host language.

The experiments are designed to address several questions. Is pure XSLT faster in all cases? Can user extension functions be used to improve performance for certain classes of tasks? What overheads are introduced when invoking host-language functions from XSLT, and under what circumstances should such functions be avoided? By examining both computational and XML-processing workloads, we aim to identify the situations in which extension functions provide the greatest benefit and the trade-offs involved in their use.

Conclusion

In summary, the results show that combining XSLT or XQuery with host-language user-defined extension functions can significantly improve performance. However, their use should be guided by the nature of the task being performed.

Extension functions should be viewed as a powerful tool for addressing computationally intensive operations or tasks that are difficult to express efficiently in XSLT or XQuery alone. In some cases, the performance gains may arise from limitations or inefficiencies in the implementation of a particular XSLT or XQuery solution. Where there is a substantial performance gap, as demonstrated by the math square root benchmark and other computationally intensive or recursive operations, the use of a host-language extension function can provide dramatic improvements in execution time.

By contrast, for XML-centric operations such as tree navigation and predicate evaluation, pure XSLT often remains the most efficient solution. This is particularly true when the XPath optimizer finds an smart execution strategy, for example, construction of an index as in this example.Developers should therefore consider extension functions selectively, using them where they provide a clear benefit while continuing to rely on the strengths of the XSLT and XQuery processing model for document-oriented tasks.