Re: Antwort: Re: Performance of XPathEvaluator operating on Xerces DOM

[david_n_bertoni]

Hi Joerg,

Please make sure you reply to the list, not to me directly.

Here's the problem:

>    XalanDocument *xalan_document =
parser_liaison.createDocument(&document, false, false);
>    assert(xalan_document != 0);

The buildWrapper parameter should be true for better performance:

    XalanDocument *xalan_document =
parser_liaison.createDocument(&document, false, true);
    assert(xalan_document != 0);

Otherwise, the wrapper will not index the nodes in document order, and
Xalan-C will consume lots of CPU cycles ordering node-sets.

If you're going to use XercesDocumentWrapper, make sure you always re-build
the wrapper after you've made modifications to the document, and make sure
you pass true for the buildWrapper parameter.

Dave



|---------+------------------------------>
|         |           [EMAIL PROTECTED]|
|         |           formatik.de        |
|         |                              |
|         |           06/25/2003 03:19 AM|
|---------+------------------------------>
  
>---------------------------------------------------------------------------------------------------------------|
  |                                                                             
                                  |
  |        To:      [EMAIL PROTECTED]                                           
                         |
  |        cc:                                                                  
                                  |
  |        Subject: Antwort: Re: Performance of XPathEvaluator operating on 
Xerces DOM                            |
  
>---------------------------------------------------------------------------------------------------------------|




Hi David,

thanks for the quick reply.

Here's the requested code snippet taken directly from
a test example:

void process12(xercesc::DOMDocument &document)
{
    XercesDOMSupport dom_support;
    XercesParserLiaison parser_liaison;

    XalanDocument *xalan_document =
parser_liaison.createDocument(&document, false, false);
    assert(xalan_document != 0);

    //XercesDocumentWrapper *document_wrapper =
parser_liaison.mapDocumentToWrapper(xalan_document);

    XPathEvaluator evaluator;

    XalanNode * root_context_node = xalan_document;
    assert(root_context_node != 0);

    XalanElement *namespace_node = xalan_document->getDocumentElement();
    assert(namespace_node != 0);

    std::string xpath = ....  // as before

    const XalanDOMString expression(xpath.c_str());

    NodeRefList nl = evaluator.selectNodeList(
                                        dom_support,
                                        root_context_node,
                                        expression.c_str(),
                                        namespace_node);

    NodeRefListBase::size_type len = nl.getLength();

    std::cout << len << " nodes selcted\n";
}

The XercesDocumentWrapper is not used in this code as it is only
a stripped down example to exhibit the problem. However, in the
production code (or what will be production code, eventually) it
is used like this.

XalanNode *xalan_node= nl.item(i);
const DOMNode *xerces_node = document_wrapper->mapNode(xalan_node);

This should answer your questions. By the way, I forgot to tell you
that I tried both Xerces and Xalan binary distributions right out
of the box as well as versions compiled out of the sources (no
Dinkumware fixes applied to our VC6!). Both show the same behaviour.

Before I prepared the stripped down example and turned to you
I also tried to narrow the context for the XPath expression evaluation
by locating a context node to be used via selectSingleNode() and this

"/Model/Business"
"/FLNBenutzerCLASS"
"/FLNUserclassCLASS"
"/FLNWerkstattBerechtigungCLASS[WerkstattBerechtigungCLASS/ZugelasseneWerkstatt
 = /Model/Intern/AuswahlInfo/AusgewaehlteWerkstatt]"
"/FLNWerkstattCLASS"
"/FLNAnlageCLASS[AnlageCLASS/Anlage =
/Model/Intern/AuswahlInfo/AusgewaehlteAnlage]"
"/FLNMDETerminalCLASS"
"/FLNTagesSummenCLASS[position() =
/Model/Intern/AuswahlInfo/AusgewaehlteTagesSummen]"

and applied selectNodeList() on the returned context node with the
following expression:

"FLNZustandsWechselCLASS[ZustandsWechselCLASS/AktuellerZustand = 'PROD']"
"/ZustandsWechselCLASS"
"/ZeitSummeZustandBeiEnde"

The results are the same. If I leave out the last two location steps
it works fast, if I include them it slows down.

I also need to mention that locating such a context node does not
pose a problem since the bulk of our data is in the nodes below the
FLNTagesSummenCLASS element and there is always exactly one such thing
adressed by the expression above.

Experimenting with the booleans on parser_liaison.createDocument(...)
or with parser_liaison.setBuildWrapperNodes(true) did not help either.
I was able to evaluate the expression but mapping XalanNode(s) back
to XercesNode(s) provided me with NULL-pointers. However, I cannot
remember the exact sequence of calls I performed.

So what would be the propper sequence of steps to build this
Xerces/Xalan-adaptation structure in advance and would that help?

If you need more input from my side, please ask for it.
I'd be glad to provide it.

Thanks for investigating this effect.

Regards
Joerg Seidler

[EMAIL PROTECTED]