Pages: 1
Print
Author Topic: XMetaL opens very slow with 2.61 MB File  (Read 5827 times)
chandan7891
Member

Posts: 23


« on: November 24, 2010, 03:35:11 AM »

Hi,

I am opening a XML file of 2.61 MB using XMetaL 5.5 Author and its taking 34 Seconds. The file is located in my C: Drive. I am not using any styles in the XML doc. I have used the identifier as SYSTEM in the Doctype declaration. My system configuration is:

3GB RAM
Intel Core 2 Duo Processor with 2.00 GHZ Processor.
Microsoft XP with Service Pack 2

Could you please suggest the reason for the slow speed? Are there any workaround exist? Thanks.

Chandan



Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2618



WWW
« Reply #1 on: November 24, 2010, 11:40:41 AM »

The product needs to build an XML DOM, and an editable rendition of the document using CSS. These are the two main things that take time, not just reading in the XML (which should be just as fast as any other non-XML-aware editing software).

A lot of other things may occur during opening (various events fire to run scripts, etc) but if you have just a CSS and CTM file (which are the absolute minimum files the product requires in addition to the schema) then you are probably seeing the document open at about the fastest possible speed.

If you have not used other XML editing software with similar capabilities you might think that 34 seconds is slow. Perhaps you are comparing this to a web browser (where the rendering is "static" -- does not accept user input) or to a simple text or XML editor that does not provide similar capabilities.

You may wish to open the document directly into Plain Text view. In this view (which does not build an XML DOM and does not render the document using CSS) the document will open faster. If you then switch to Tags On view from Plain Text view you will see that the majority of time opening is used to build the DOM and CSS rendering.
« Last Edit: November 24, 2010, 11:42:49 AM by Derek Read » Logged
chandan7891
Member

Posts: 23


« Reply #2 on: November 25, 2010, 04:58:12 AM »

hi
But while opening the same document in epic editior version5.4 it is takeing 8 sec with the same configuration of the laptop....

can you plese suggest why xmetal is too slow in compare to epic.....
Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2618



WWW
« Reply #3 on: November 25, 2010, 05:40:19 PM »

If both products are running on the same physical machine, or at least identical hardware, then the configuration you have for Epic might just be better optimized, or perhaps your Epic customization is providing fewer features. We are really guessing here at this point. It could be that one product just deals better with a particular schema or XML file's document structure than the other.

However, it is possible that you can make some changes to the customization used for your  documents that will speed things up. If the customization was not created by you and there are specific things you notice about it you may wish to contact the maker to ask if they can improve those features. If you made the customization yourself you could provide XMetaL Support with a sample (XML file, DTD/XSD and customization files including CSS, CTM, MCR, etc) so they can have a look and see if any improvements can be made.

Things you could do would be to simplify complex CSS, scripts that take a long time to run could be improved or perhaps turned off, etc.
« Last Edit: November 25, 2010, 05:41:51 PM by Derek Read » Logged
chandan7891
Member

Posts: 23


« Reply #4 on: November 25, 2010, 10:38:30 PM »

hi but the speed that i am mentioning is with out any customization files of xmetal.....no css no ctm etc only dtd and xml.....taht's why i am worried....
Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2618



WWW
« Reply #5 on: November 26, 2010, 08:11:45 PM »

There is always a CSS and CTM file. You cannot get around that.

If you do not provided these files with the DTD or XSD for your XML file then the product has auto-generated these files for you and they might be sub-optimal.

The product makes a best guess based on the element names, attribute names, and their relationship to each other but this logic is limited (to well-known English language names only) because it is really expected that a proper customization will be provided for any particular schema. This is the purpose of the XMetaL Developer product, the reason our Professional Services team exists and why we partner with companies that specialize in creating customizations for XMetaL.
Logged
sapraaman
Member

Posts: 17


« Reply #6 on: November 27, 2010, 01:19:26 AM »

Hi Derek, are you suggesting that out of the box, XMetal would perform slowly unless it is optimized by your professional services team?

Can you please guide further on what optimizations are you hinting at? Do you have any documentation or guides which suggest on how to improve XMetal performance?

We are in the process of transition to XMetal, but considering that XMetal is performing at half the speed of the previous tool, we are facing lot of reluctance and issues. Thats why we performed a simple test of loading a 2.x MB file in both the editors to give you an idea.

Please suggest.

Thanks,
Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2618



WWW
« Reply #7 on: November 27, 2010, 02:46:52 AM »

No, that is not normally the case. I am suggesting however, given the right schema (DTD or XSD) that it may perform sub-optimally if you have not properly designed a customization for your particular schema. It is impossible to know what the behavior might be unless we are provided with a copy of the schema in question. If a customization is auto-generated (which seems to be what has been done in your case) then it is very possible that the customization is sub-optimal because a human has not properly designed it. However, whether or not performance appears to be slow, it is always in your user's best interest to provide a properly-designed customization (designed by a human) for every DTD or XSD used with XMetaL.

In the extreme case, if you have unrecognized element and attribute names (such as <foo>, <bar>, <baz> versus recognized commonly used names such as <p>, <para>, <paragraph>, <img>, <image>, <graphic>, etc.) then the auto-customized CTM  and CSS files will not give your users a good editing experience. The auto-customization generator is tuned for elements that match names commonly used with very common DTDs, such as HTML, XHTML, DOCBOOK and similar.

In the worst case scenario you may have a customization auto-generated that does not recognize that an element should be treated as a paragraph or as an image or graphic element, or as a list, or a table, etc, or that an element is incorrectly displayed as block versus inline or whether whitespace is significant as in a <pre> (for HTML / XHTML) or <codeblock> (DITA and similar) element. When this happens an element might incorrectly display using CSS display:block or display:inline or whitespace:pre settings or the CTM settings might not be set correctly. Either way, performance may suffer, but also the incorrect display settings simply might not be set so the author will see something they do not expect.

I have seen some US military DTDs where element names are very cryptic (names similar to <a41b> which even a normal human cannot readily decipher without documentation) that our auto-gen code just assigns CSS "display:block" to and no other settings. You could easily correct the rendering by using XMetaL Developer (assuming you understand the schema yourself and have a preference for how the element should be rendered).

This auto-generation (of CSS and CTM files) is meant to be used as a last-ditch solution for authors who have not been given a proper customization from an XMetaL developer (someone that designs customizations) and is really just a best guess so the document author can at least edit their documents to some limited degree (perhaps in an inconvenient and less optimal fashion but in a way that still allows them to do something).

XMetaL Author is really meant to be properly customized on a per-DTD or per-XSD level so that you provide your authors with a nice editing experience, removing the complexity of needing to understand all the nuances of schema and XML rules that would be necessary for an author understand if they were using other authoring tools. The product is able to provide a fairly standard editing experience in some limited cases when no customization is provided (beyond the DTD or XSD file) but the real power of the product is the extensibility that it provides with its 1200+ APIs, CSS level 1 and 2 support for rendering, as well as the (XMetaL proprietary) CTM settings, XFT forms support, etc. These things can generally only be truly taken advantage of when you take the time to design a proper customization (which means reading the Programmer and Customization guides and implementing a complete solution for your particular schema and delivering these files to your authors in addition to simply providing the DTD or XSD).

Ultimately, it is expected that you provide a properly designed CSS and CTM file (and possibly other functionality provided by XFT, MCR and other files) with the DTD or XSD file your users are authoring to. This is no different from any of our competitors. The file types (file extensions) will be different but they require some kind of additional "customization" files to be provided for each DTD or XSD in order to provide users with an optimal editing experience.

For DITA authoring, XMetaL Author Enterprise includes such a customization out of the box. For any other document type you (as a customizer) are expected to provided such a solution for your end users for your particular DTD or Schema.

So, again, I would suggest that if you are unhappy with the performance of the customization you are currently using you should provide XMetaL Support with a copy so that they can look at it to see if there is anything they can suggest. If you have not specifically designed a CSS or CTM file then provide them with a copy of the XML and the DTD / XSD file so that they can have a look anyway. Perhaps the auto-generated CSS and/or CTM file can be improved. If not, then you might be looking at the very best possible performance you can expect from the product given your DTD or XSD and this paricular 2.61MB XML file.
« Last Edit: November 27, 2010, 02:53:14 AM by Derek Read » Logged
Pages: 1
Print
Jump to:  

email us