axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Samisa Abeysinghe <>
Subject Re: Possible improvements to Axis2/C
Date Mon, 02 Jun 2008 11:51:39 GMT
Supun Kamburugamuva wrote:
> Hi All,
> At the moment Axis2/C is considerably faster than its Java 
> implementation. We have run performance tests for Axis2/C and the 
> results are promising. But we believe that we can improve the Axis2/C 
> performance to a much higher level than what it has achieved.
> I have done profiling for Axis2/C on a Windows machine using the 
> Benchmark service and Apache "ab". These tests were done using both 
> Apache web server (httpd) and Simple Http Server. These results didn't 
> show any routines which cause bottlenecks in the Axis2/C. Also 
> Guththila is at its best and I cannot think of any major improvements 
> to the Guththila which can cause a major performance improvement.
> So the conclusion is that if we want to improve the performance we 
> need to do it in a distributed way. We need to improve the little 
> things that are unnoticed and not cared for that adds up at the end.
> There is another way that we may be able to improve the performance of 
> Axis2/C drastically. But to do that we need to do design level changes 
> to Axis2/C. I will explain one such improvement that can be done.
> When Guththila parses a XML, it tokenize the buffer. Please note that 
> these tokens are not strings, they are pointers to the actual XML 
> buffer. But Axiom/C is designed in such a way that it needs a copy of 
> every XML entity (element name, attribute name, name space, element 
> prefix, text value etc) for it to keep. So when Axiom/C model is build 
> from the Guththila parser, Guththila copies the strings from the XML 
> buffer to a new string (this requires new memory allocation and memory 
> copying). Here we are duplicating the information that we already 
> have. This gives cleaner design and a robust code (Java style of doing 
> things). But it is not a good thing in a performance point of view.
> So in the new design, Axiom/C can be built without assuming ownership 
> of the strings. Here we are not passing a copy of a string from parser 
> to Axiom/C. Instead a pointer to the buffer(starting positions of the 
> string) is passed. Axiom/C won't free this new string because it 
> doesn't have ownership to the strings. At the end we free the XML 
> buffer and we don't have to worry about freeing each and every 
> individual strings. Here we don't need to change anything beyond the 
> Axiom/C level. Also Guththila is designed to handle this and we don't 
> need to do any changes to Guththila.

This can be done without changing the current API?


> Another improvement is to reuse the things that are used always. I 
> haven't looked at this at a deep level but for starting things, we may 
> be able to reuse things like SOAP name space strings, envelope name, 
> header name etc.
> Regards,
> Supun..
> ------------------------------------------------------------------------
> No virus found in this incoming message.
> Checked by AVG. 
> Version: 8.0.100 / Virus Database: 269.24.4/1477 - Release Date: 6/1/2008 5:28 PM

Samisa Abeysinghe 
Director, Engineering; WSO2 Inc. - "The Open Source SOA Company"

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message