Hi Neil, You are right the "per-document memory heap" in Xerces's DOM implementation is still there. I missed that when I looked at the source code.
My application accepts XML messages, parses them into DOM, converts DOM to messages in a proprietory format and send them to a server. When response messages come back from the server, my application parses the proprietory response message and builds DOM, it then serialize DOM into XML byte stream and send out. We use expat to do the parsing because for better performance. So the functionalities we actually use from Xerces is DOM building and serialization. The validation was not included. Thanks, Wenning Qiu -----Original Message----- From: Neil Graham [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 27, 2004 2:56 PM To: [EMAIL PROTECTED] Subject: RE: Performance degradation Hi Wenning, If by the "per-document memory heap" you're referring to the way Xerces's DOM implementation works, then nothing has changed since 2.2. The same memory paradigm is used. The pluggable memory management certainly does introduce overhead: every time the parser needs memory, it has to reach out to a virtual function instead of directly calling the system libraries. Some work was done to mitigate the parser's habit of creating and destroying short-lived objects in the 2.4 time-frame, and this bought back a good portion of the performance that the pluggable memory scheme cost. To be more helpful, we'd have to understand the characteristics of your application. I conjecture you're DOM-based; do you do any validation? If so, then some of the grammar caching/persistence capabilities introduced since 2.3 might be helpful to you. Cheers, Neil Neil Graham XML Parser Development IBM Toronto Lab Phone: 905-413-3519, T/L 969-3519 E-mail: [EMAIL PROTECTED] "Qiu, Wenning" <[EMAIL PROTECTED] To: <[EMAIL PROTECTED]> ystems.com> cc: Subject: RE: Performance degradation 04/27/2004 03:29 PM Please respond to xerces-c-dev I've yet to Quantify my application. But as I took a brief look at the xercesc.2.3.0 source code, it seems that the per-document memory heap is gone with the introduction of pluggable memory manager. The default memory manager just turns around and calls new() and delete(). This means higher overhead for handling large number of small objects. I suspect that the default memory manager causes the performance degradation. I have to wait for my application to be quantified to prove that. Is the per-document memory heap logic provided somewhere in the source distribution as a memory manager implemantation? It seems more reasonable to provide that as the default memory manager. -----Original Message----- From: Jesse Pelton [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 27, 2004 9:24 AM To: [EMAIL PROTECTED] Subject: RE: Performance degradation Hmm. I wonder if the pluggable memory manager introduced in 2.3 is responsible for the degradation. If I understand your benchmarks correctly, changing from Xerces 2.2 or earlier to 2.3 or later results in a 28% decrease in message throughput, from 50/sec to 36/sec. That's pretty serious. Can you profile your application to see if there are any obvious bottlenecks in Xerces or elsewhere? Knowing where the problem lies would help you and/or the maintainers address it. From: Qiu, Wenning [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 27, 2004 9:59 AM To: [EMAIL PROTECTED] Subject: Performance degradation Hi, All We have observed a performance degradation when upgrading some third-party packages in our production systems. We are currently using xercesc.2.1.0 with STLport.4.5.3, libhoard.2.1.0 and expat.1.95.4. We are looking at upgrading to xercesc.2.5.0, STLport.4.6.2, libhoard.2.1.2d and expat.1.95.7. Our current production code can process about 40 messages per CPU-second in our test environment, while the new build with all new 3-rd party packages can do only 36 per CPU-second. However, when built with xercesc.2.1.0(or 2.2.0), STLport.4.6.2, libhoard.2.1.2d and expat.1.95.7, it can handle close to 50 mesages per CPU-second. We have tested all xercesc releases since 2.1.0, it seems that the performance drop started since 2.3.0 and remained till the latest release. Is there a way to turn off the unwanted features in the new releases so that good performance is retained? Does anybody have any idea when performance is to be addressed in future releases? For now it looks like we can move up to 2.2.0 at best since the performance is of great importance for our system. Thanks for any feedback. Wenning Qiu CSG Systems Inc. Phone: (402)963-8364 Email: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
