Pages: 1
Print
Author Topic: Xmetal very slow opening documents  (Read 1967 times)
gcrews
Member

Posts: 265


« on: November 27, 2013, 10:41:48 AM »

XmetaL Author Enterprise: Version#: 7.0.0.111

Is there any way to trace or profile Xmetal to see what's causing long delays.  We have many files larger than 500KB. Xmetal takes over 3.5min just to open a 1MB XML file which is unacceptable. I have even turned off refreshing references when opening topics. How do I find out what is causing the long delays  so I can resolve them?
Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2579



WWW
« Reply #1 on: November 27, 2013, 01:01:42 PM »

There is no logging for this type of thing. The first thing I would try (if you have control over your customization) is to replace your CSS file with a zero length file (empty). If that speeds things up considerably then add portions of it back.

If that does not help at all then I would look at your MCR file to see if it is doing something significant during file opening and initial rendering. Stepping through your code with a debugger may pinpoint something. If something is identified that looks like it is taking a long time it is possible to time it by use of the Date() object (if using JScript). Create a new Date() at the start of what you want to time, then another at the end, and then subtract the two to get milliseconds. Keep in mind that a lot of script that runs at startup is part of the XMetaL Author application (and differs depending on whether you are running Essential or Enterprise) and CMS integrations also do things at application startup as well as document loading.

One known issue with rendering speeds and CSS is the background-color and border properties. If these are set on significant portions of a large document (ie: the root element, or similar large sections) that will slow rendering down.

If your customization includes a lot of inline XFT forms (XFT forms that are embedded inside the document to replace certain elements) that is another potential bottleneck in rendering speed. An XFT form might also contain code that needs to finish before it is rendered. The best strategy in such a case is to convert as many of these forms as possible to other types of UI. That will vary depending on what the forms do. In some cases we have seen clients use them instead of using toolbars, so putting their functionality into a toolbar or the context menu might be possible. When that doesn't make sense, and the form is used for inputting data, then changing it to a dialog (so that it opens when the element is clicked on) will speed up rendering of the document.
« Last Edit: November 27, 2013, 02:03:34 PM by Derek Read » Logged
gcrews
Member

Posts: 265


« Reply #2 on: November 27, 2013, 03:01:20 PM »

Thanks for the quick reply. I have not done any customizations to XFT forums. I tested a few things you suggested and here are the results. The test file I was using as well as many others we have  are recently converted XHTML files to DITA.


XMetaL(R) Author Enterprise - 7.0.0.111
Refreshing references when opening topic disabled
1MB DITA 1.1 XML file

Code:
Initial Load Time:                      2min 50sec
After removal of table with 509 xref's: 2min 02sec
After removal of remaining 655 xref's:  1min 45sec
After removal of all customized CSS:    1min 35sec
After removal of MCR's & CMS connector: 1min 30sec
After empty concept_ditabase.css:       1min 02sec
Disabled spell check while typing:      1min 02sec
Cut file content in half(just  a test):      30sec

Load Time for original XHTML file:           12sec

Is there any way to get opening, switching views, saving documents, ...ect anywhere near the performance that we saw when editing XHTML documents?  We were not exactly expecting the switch from XHTML files to DITA to take 12 times as long to operate in XmetaL
« Last Edit: November 27, 2013, 03:07:25 PM by gcrews » Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2579



WWW
« Reply #3 on: November 27, 2013, 04:07:22 PM »

Sorry, I guess I should have answered in the context of the DITA customization, which of course you don't have much control over (at least the script portions are off limits). The DITA solution uses no embedded XFT (so that's a red herring, sorry again).

The DITA customization is quite complex and tested for use with smaller files (since DITA is generally a topic based solution and topics tend to be quite small). Turning off "refresh references" in DITA Options should make a significant difference if you have a large number of xrefs in a large document.

The DITA CSS files were designed to use the @class attribute for all selectors, which makes them more inefficient than if selectors that use an element name were used, but usable universally with any DITA DTD including any specialized DTD. If we were to ship a set of CSS files rewritten for people that do not specialize I think that would likely be the most significant change. We have considered this but as most people are working with DITA maps and small topics it would (as a percentage of clients) help relatively few people (very large topics + no specialization).

The spell check while typing feature should not affect opening speed much (as your test suggests) as it is optimized to spell check only the visible portion of the document.
Logged
Pages: 1
Print
Jump to:  

email us