hi Supun, On Mon, Jun 2, 2008 at 10:34 AM, Supun Kamburugamuva <[EMAIL PROTECTED]> 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. 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 stacks. -Rajika > 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 - http://groups.google.com/group/comp.lang.c/topics
