[xsd-users] in memory footprint

Rizzuto, Raymond Raymond.Rizzuto at sig.com
Fri Oct 10 13:05:25 EDT 2008


One thing I forgot to mention is that I am using xerces 2.7, mainly because that is what the company standard currently is.

I decided to set a breakpoint at the mem_allocate method, and look at any unusual allocations.  I see some that seem that way to me:

mem_allocate (s=65536) at SDMPTest.cpp:60
#1  0x08058945 in operator new (size=65536) at SDMPTest.cpp:152
#2  0x405a610c in xercesc_2_7::MemoryManagerImpl::allocate () from /siglinux/tc/sles9sp4_gcc-3.3.3_i686/sig1/xerces-c-2.7.0/lib/libxerces-c.so.27
#3  0x405447a1 in xercesc_2_7::DOMDocumentImpl::allocate () from /siglinux/tc/sles9sp4_gcc-3.3.3_i686/sig1/xerces-c-2.7.0/lib/libxerces-c.so.27
#4  0x40542242 in xercesc_2_7::DOMDocumentImpl::DOMDocumentImpl () from /siglinux/tc/sles9sp4_gcc-3.3.3_i686/sig1/xerces-c-2.7.0/lib/libxerces-c.so.27
#5  0x405532c7 in xercesc_2_7::DOMImplementationImpl::createDocument () from /siglinux/tc/sles9sp4_gcc-3.3.3_i686/sig1/xerces-c-2.7.0/lib/libxerces-c.so.27
#6  0x4030f70f in xsd::cxx::xml::dom::create_document<char> () at ../../../../../../Include/xsd/cxx/xml/dom/wildcard-source.txx:32
#7  0x401a9271 in Venue (this=0x811371c, id=@0xbfffeda0) at SDMP.cpp:11091
#8  0x0805eaa1 in Converter (this=0x81136e0) at SDMPTest.cpp:772
#9  0x08060e29 in Converter::instance () at SDMPTest.cpp:259
#10 0x0805f60f in main (argc=1, argv=0xbfffeea4) at SDMPTest.cpp:809

I see a similar back trace for each constructor.

I made a couple of changes to my options file:

1) removed --generate-wildcard
2) changed --root-element-all to --root-element message since I only ever serialize message

This seems to have made a significant improvement - the memory footprint is appox. 4k now!

I'm not sure which of those 2 changes, or both, were responsible, but I am very glad for that memory usage is now 1/300th of what it was!

Ray

-----Original Message-----
From: Boris Kolpackov [mailto:boris at codesynthesis.com]
Sent: Friday, October 10, 2008 10:19 AM
To: Rizzuto, Raymond
Cc: xsd-users at codesynthesis.com
Subject: Re: [xsd-users] in memory footprint

Hi Ray,

Rizzuto, Raymond <Raymond.Rizzuto at sig.com> writes:

> The slow exit was all the static allocations being deallocated,
> and the memory tracker not finding them because of the mem_reset's.

Yes, it is a very crude memory profiler ;-). It slows down memory
allocations/deallocations significantly due to the linear search
used in mem_map. The speed of the test shouldn't be used as any
kind of indication of what it will be in the actual application.

Boris


IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.




More information about the xsd-users mailing list