RE: Performance degradation

[Qiu, Wenning]

Title: Performance degradation

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]