xerces-c-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Altman, Drora" <dalt...@nds.com>
Subject RE: Right usage of xerces
Date Tue, 21 Jul 2009 05:51:15 GMT

I tried to do what suggested to me, adopted the document and released the parser, but it didn't
help much to reduce the memory consumption.
So I made the following trials which didn't succeed too much. Could you please help me figure
out what I'm doing wrong and how should I do it correctly?
1. I tried to import the root node and release the document.
        After the call to DOMDocumentImpl::release() some memory is released, but:
        a. not all memory (used memory is more than what was before starting to use xerces)
        b. after releasing the memory, I couldn't use the root node anymore since it's corrupted
after the document's released.
2. I saw that there is an adoptNode() function, so I tried to use it- adopt the root node
and than release
   the document.
        However, when trying this I got an exception, so I looked at the source code and found
that in xerces 2.8.0 adoptNode() has the following implementation:

DOMNode* DOMDocumentImpl::adoptNode(DOMNode*) {
    throw DOMException(DOMException::NOT_SUPPORTED_ERR, 0, getMemoryManager());
    return 0;

I looked at the source code of xerces 3.0.1 which has different implementation to that function,
however, it didn't seem to do what I expected it to do (bottom line is, that using it didn't
help either)

- Eventually, I don't know how can I release the memory allocated by xerces....

Another issue that I realized is:  I saw that we use (quite a lot) the function:
DOMNodeList *DOMElementImpl::getElementsByTagName(const XMLCh *tagname) const
I wondered when (and by whom) should the returned DOMNodeList* be deleted, I saw an answer
regarding this issue in the following link:
but didn't understand what is the meaning of: Memory for any returned object ... are owned
by implementation - whose implementation?
I think that releasing these lists after we used finished using them might help us as well
(I saw that the fNodeListPool is cleaned up when the document is deleted, but it is not explicitly
deleted in any place I could find)

Thanks in advance,
Drora Altman

-----Original Message-----
From: David Bertoni [mailto:dbertoni@apache.org]
Sent: Wednesday, July 15, 2009 9:03 PM
To: c-users@xerces.apache.org
Subject: Re: Right usage of xerces

Altman, Drora wrote:
> Hi,
> We have a project that uses xerces (2.8.0) in order to parse xml files. We allocate the
data as a DOM object in memory and work on it (adding/deleting nodes).
> The xml are quiet big.
> It seems that we miss something in the right usage of xerces, since the application consumes
a lot of memory and it does not seem to be released properly.
> During our investigation of the code, I realized that the code uses the importNode function,
which, as far as I understand, allocates the memory. This brings me to the following questions:
> 1. What's the difference between the importNode() & cloneNode() functions?
importNode() essentially clones a node from another document so you can add it to the target

> 2. How can we actually delete the memory allocated by import\cloneNode if we delete this
node afterwards?
All of the memory for nodes is allocated from a pool owned by the document instance. There
is no way to recover memory for individual nodes.

> 3. What are your general recommendations, regarding cleanup memory at the end of the
usage of xerces?
If your usage model involves creating and releasing lots of nodes, you might want to consider
"compacting" a document by cloning the entire document node and releasing the original document.
If you created the original document using a parser, remember the document instance itself
is owned by the parser, unless you call adoptDocument() on the parser instance.


This message is confidential and intended only for the addressee. If you have received this
message in error, please immediately notify the postmaster@nds.com and delete it from your
system as well as any copies. The content of e-mails as well as traffic data may be monitored
by NDS for employment and security purposes.
To protect the environment please do not print this e-mail unless necessary.

An NDS Group Limited company. www.nds.com

View raw message