Reply To: XMetaL Author Essent 12:the typing is lagging (slow) with increase of text size

[Derek Read]

This is true in general: the larger a document is the slower interactions with that document will be.

However, 110KB is nowhere near what I would consider to be “large”. I would say that's pretty small. We have clients that work with multi-MB sized documents. In some cases editing is “slow” but that depends on much more than simply XML file size. As an example, the sample “CamerasInFocus.xml” (that uses the fairly complex journalist.dtd) ships at 8KB. After copying and pasting content in that document to increase overall content size to 1.5MB I see no reduction in authoring interactions other than an increase in save time (which also does a full document validation by default), increasing from less than 1 second (at 8KB) to several seconds (at 1.5MB).

So, here are some things to look at:

The complexity of the document itself and the complexity of the schema (DTD or XSD) can contribute. In other words, a document consisting of one element containing thousands of lines of text will be easier on the software than a document with thousands of elements each containing a small amount of text. A document containing complex validation rules can also slow editing (complexity of the schema). In other words, if the software needs to decide between many elements, attributes, or values when inserting or changing or validating those things vs a simpler schema where there are only a few options editing the latter will be faster. These issues are primarily related to how XMetaL Author uses its “rules checking” feature to stop users from putting a document into an invalid state.

If none of the things below help then the primary strategy in this case would be to reduce document size (if the schema is not the issue or the schema cannot be altered) and then piece together multiple smaller documents when transforming the XML to its final output (if that is necessary).

Additional things that will slow editing include the complexity of the CSS used to render the document in Tags On and Normal view as well as macros that run when various actions take place. The CTM file can also have an effect, primarily if it contains script or if it is configured to render XFT forms with complicated scripting code or display many XFT documents inline in a document.

The “check spelling while typing” feature can also slow editing, so it makes sense to try turning that off, as you have done.

The “bidirectional text” feature (which is off by default) can drastically reduce editing speed, depending on which languages are being rendered, so if you don't need that feature make sure it is off.

You might try a test where you replace your CSS file and CTM file with empty files to see if that helps. If it does help then replace portions of those files until the issue returns to find out what is contributing to the slow down.

Macros that fire frequently (such as On_Update_UI) can slow down document editing, as well as macros that run less frequently but contain complex code, or macros that are relying on some external service to respond (these would typically be found with CMS integrations or systems that help with language such as spelling, grammar, controlled language database, etc).

The rendering of tables in a document can be slow, depending on the table type. HTML tables are auto-sized so they can be slower than CALS to render while users are making changes to content within them. Very large tables in general are slow (all table types). The only solution here is to reduce their size, which typically means breaking large tables into pieces then joining them together during output transformation if the final output requires that.

Note that the issues above generally don't apply to Plain Text view as most of the features mentioned won't function in that view, or if they do they function in a much simpler way.

Reply