axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rajika Kumarasiri" <>
Subject Re: Possible improvements to Axis2/C
Date Mon, 02 Jun 2008 06:54:50 GMT
hi Supun,
On Mon, Jun 2, 2008 at 10:34 AM, Supun Kamburugamuva <>

> 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.

I too did a performance test and a profiling test on linux platform using
the KCahegrind profiling tool. The result which was given support your
argument that we need to improve the logics of the independent
codes(functions) in a distributed manner in the entire code base.

IMHO I think  a good start would be to reduce the self time of the functions
by re-implementing their logic(if possible) without changing their call


> 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.
> 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..

comp.lang.c -

View raw message