axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Supun Kamburugamuva" <>
Subject Possible improvements to Axis2/C
Date Mon, 02 Jun 2008 05:04:29 GMT
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.

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.


View raw message