axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Supun Kamburugamuva" <>
Subject Re: Possible improvements to Axis2/C
Date Mon, 02 Jun 2008 13:16:44 GMT
AFAIK yes we can do this. The only thing is we need to introduce the
axutil_string_t to every structure in axiom/C for handling the strings (most
of these are already done). When we create these strings we set the
owns_buffer to false. When Axiom/C free the axutil_string_t structure it
won't free the actual buffer. We can free the actual buffer at the end of
the processing of the request and every string buffer will be free at once.

Also with the current design all the methods in Axiom/C returns the strings
to the users but the ownership of those strings remains with Axiom/C. So
hopefully we won't have to worry about that also.


On Mon, Jun 2, 2008 at 4:51 AM, Samisa Abeysinghe <> wrote:

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