This guide describes how different of areas can influence the performance of the editor and what you can do to optimize those areas.
XPaths and performance
FontoXML uses XPaths for a lot of APIs. Most of these trigger an update when the result changes because of user input. Fonto does this by recording which DOM properties are accessed by an XPath query.
We have explained our approach in more detail during XML Prague 2017.
FontoXML does not yet automatically speed up any XPath queries, though this is planned for a future release. If an instance experiences performance related issues, it may be worth the effort to manually go over the registered XPaths to optimize them.
To guarantee an acceptable performance, some manual optimizations may be needed to prevent an XPath query from accessing too many DOM properties.
Avoid full document scans
Full document scans (or traversing a large part of the document) should be avoided, unless they are absolutely necessary. If a developer knows a certain element can only occur in a certain subtree of the document, it is more efficient to only traverse that part. For example: If the element articleNumber can only occur as a descendant of
/metadata/article/otherInfo, the XPath query
/metadata/article/otherInfo/descendant::articleNumber will perform better than
Ordering of operands
FontoXPath evaluates binary boolean operands (and, or) left to right. This can be leveraged to optimize some XPath queries.
self::someElement[(let $id := @id return //@idref=$id) and @needsRef]
This XPath needs a full document scan, even if the
@needsRef attribute is absent. By swapping the operands around, the XPath can skip the next operand.
self::someElement[@needsRef and (let $id := @id return //@idref=$id)]
If the instance performs normally, but only experiences a slowdown when changing the children of an element, it could very well be a pattern like this.
An attribute index allows quick lookup of an element by the value of one of its attributes. This will create a index of all elements with that attribute, which will do a full document scan at startup of the application and be kept up to date by tracking changes made to the document. See addAttributeIndex for configuration and how to use.
We recommend introducing an attribute index to prevent full document scans. Instead of writing
//[@id=$rid] you can prevent the full document scan by adding a index on the id attribute and writing
Especially with CVK and SVK configuration, FontoXML tries to bucket XPath selectors by the type of node they'll match. When examining the CVK properties of a node, only selectors in buckets which are applicable for the given element are evaluated. For example: the selector
self::processing-instruction() never has to be evaluate for whichever element and the selector
self::p[..] will always return false when passed a
<div> element, the full XPath engine does not have to be started for this selector. For some instances, this reduces a list of hundreds of selectors to a list of only a few.
Currently, buckets are determined by examining the compiled selector. This basically attempt to find the following patterns:
||The selector is placed in the bucket for the specified nodeName. This is the preferred bucket, since it has the smallest granularity. Please note that the selector
||The selector is put in the elements bucket. It will only be executed when examining an element.|
||The selector is placed into the correct bucket for the nodeType. This causes it to be evaluated for any other selector.|
||The selector is placed in the bucket of the sub expressions if both have the same bucket. The selector has no bucket if they differ.|
||The selector is placed in the bucket of any of the subExpressions with a bucket.|
||The selector is placed into the bucket of the subExpression.|
|Most other expressions:
||The selector can not be placed in any bucket. It may be executed for any node. This should be avoided if possible.|
Toolbar tabs and performance
A toolbar tab contains multiple buttons, drops, and other UI components. These control operations, which in turn can control commands. To see whether these commands are enabled, they are executed in a sandboxed environment. The result of the command is then discarded.
Executing commands can potentially be hard, even more so in large documents. Though FontoXML is heavily optimized, having to compute the state of a lot of buttons will cost some time.
FontoXML has to compute the state of every (visible) button in the current toolbar tab. A simple way of mitigating some performance issues is to spread buttons over multiple toolbar tabs, or placing them behind drop-downs.
Example: Operation editing the order of a section-like node
When an operation can be used to reorder nodes, it implies the list of section-like nodes next to it can grow to a large number. This causes a large part of the document to be validated. This is a usual cause of performance loss. This can be mitigated by placing the operation into the structure view as a contextual operation, ensuring its state is only recomputed when the button is about to be used.
Experimental performance improvements
Apart from reorganizing the toolbar, it is also possible to improve typing performance by enabling a number of experiments. This set changes every release, and some experiments are automatically integrated after some time.
An overview of all current experiments is also available.